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Abstract: This document is adapted from the paper by R. Rashid and G. Robertson, "Accent: 
A Communications Oriented Network Systems Kernel." Proceedings of the Eighth Symposium on 
Operating Systems Principles. 



Part One 
Introduction 



Accent is an operating system which runs on the PERQ Systems family of single user graphic 
workstations. It is the Accent operating system that permits a group of individual workstations to 
become a unified computing environment distributed across many workstations connected via 
Ethernet. To accomplish this, the design of Accent is based on a powerful communications 
abstraction. 



1.1 Messages and Communications 

Accent is a message-based operating system. All communication is provided through the 
sending and receiving of messages. The object upon which this abstraction is based is the 
Interprocess Communication (IPC) port. Ports are protected objects. The only way to gain access to 
a port is to have the Accent kernel provide that access. 

The Accent IPC system supports multiple senders and a single receiver on IPC ports. In 
addition to the multiple senders and single receiver, an Accent IPC Port also has an owner. When 
the process that has received rights to a port dies, the owner of that port is notified. This allows a 
third controlling process to establish the communication channel between two other processes. 

The IPC system is built into the operating system at the lowest levels. There are a number of 
ways in which the IPC system and other portions of the operating system interact. This will become 
apparent in later discussions of the IPC and Memory systems. 

1.2 Processes 

Accent supports the concurrent execution of multiple processes. A priority scheduling system 
with preemption and aging is used. The aging system is used to lower the priority of 
compute- bound processes. When a process completes a full time slice without blocking, the priority 
of that process is lowered. When the process blocks, its priority is raised to its original level. This 
keeps the priority of highly interactive processes high while lowering the priority of 
compute-bound processes. In order to supply a degree of fairness the time quantum is longer for 
the lower priorities. Processes are arranged in a tree of descendants. The operating system provides 
facilities that can be used to control either single processes or entire trees of processes. 

Accent provides a large paged virtual address space for processes. Each process has a 2t32 byte 
virtual address space. This space is broken into a number of 512 byte pages. In Accent it is not 
possible for processes to share portions of their address spaces. If a process wants to give another 
process access to part of its address space, the initial process sends that portion of the address space 
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to the second process in an IPC message. This is a simple mapping operation; no data is actually 
moved. 

If both processes want to have access to the data, a logical copy is made. In tins case each of the 
pages is marked CopyOn Write. As long as neither process wants to write any of the data, no copy is 
made. If either process performs a write operation to some portion of the data, the page that 
contains the data to be written is copied. It is important to note that neither process knows that this 
has happened. As far as both processes are concerned, they each have a separate copy of the data. 

1.3 The Network 

Accent is a communications oriented operating system. All requests made by clients are in the 
form of IPC messages. The IPC facilities arc extended across the Ethernet by a set of servers. It is 
important to note that the semantics of inter-machine and intra-machine IPC facilities are exactly 
the same. There is no need for a process to know if the other processes with which it is interacting 
are on the local machine or on a remote machine. Because these facilities are built into the lowest 
levels of the operating system, all operating system facilities can be provided by local or remote 
machines. 

The best feature of the network under Accent is that neither the user nor the applications writer 
needs to know that it is there. It is possible to use the system and the network without the 
knowledge that you are doing so. 

1.4 The Window Manager 

Accent provides a sophisticated window management facility. This facility is used to provide 
processes with a virtual display. The set of all processes' virtual displays are mapped onto the single 
PERQ physical display. 

The Window Manager fully supports the covered window paradigm. Processes need not know 
the current state of their windows. The Window Manager is responsible for displaying only the 
portions of a process window that are visible at any given time. 

If a window is a simple text window the Window Manager will "remember" what is in the 
window. When the state of the window changes the Window Manager will redisplay the newly 
uncovered portions of the window. 

If the window is a graphics window the application program can request the same type of 
facilities as a simple text window. This is done by keeping off-screen copies of the covered portions 
of the window. In addition to this method, applications that wish to have more control over the 
display can request a notification when the state of their windows changes. 

In addition to text and graphics output, the window manager is responsible for the control of 
the system keyboard and pointing device. Key strokes and puck presses arc provided to the 
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application as a set of abstract events. The events that are generated when keys or buttons are 
pressed can be defined by the application. The mapping of actual key and puck presses into 
abstract events is achieved by a user-alterable translation table. PERQ provides translation tables 
for all system functions. If you do not like these translations, you are free to change them, but in 
general we suggest that for system functions you use the standard translations. 

1.5 The File System 

Accent provides a virtual memory mapped file system. All access to files are the same as access 
to virtual memory. 

When a file is "opened" the file is mapped into the virtual memory of the process that opened 
the file. This is only a mapping operation; no data is moved. When a portion of the file is accessed, 
that portion is faulted into physical memory. 

To write a file, the application program first builds the file in its virtual address space. The 
application program then requests the file system to save that portion of the address space on the 
disk with a specific name. 

Of course all File System facilities work in the same manner regardless of the actual location of 
the file. Access to remote files is achieved in exactly the same manner as access to local files. 

1.6 Environments 

The Accent system provides three different user environments. The user of a system can use a 
single environment or a combination of all three. The three environments are a) Accent, b) UNIX 
software, and c) Lisp. 

The Accent environment is entered at system boot time. The interface to this environment is 
the Accent Shell. 

The UNIX software environment is provided by the Qnix system. This environment provides a 
standard Bell System V Unix. 

The Lisp environment is provided by the Common Lisp system. 

It is possible to have all of these environments running at the same time on the workstation. 
Each environment runs in a different window on the screen. To change from environment to 
environment it is only necessary to change to a different window. In a number of cases it is possible 
to make cross use of the environments. It is possible to run Accent programs from a Unix software 
shell. It is also possible to run Unix software programs from an Accent shell. 
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1.7 Organization of this Document 

The remainder of this document is organized as follows. 

Chapter 2 describes in detail the operation of the kernel of the Accent system. If you are not 
interested in the details of the operation of the system, you may skip this chapter. 

Chapter 3 provides an overview of the major servers in the system. 

Chapter 4 provides information about each of the three different environments available on the 
system. 

Chapter 5 provides programming examples. This is the most interesting chapter for most users 
of this document. 
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Part Two 
System Structures 

This chapter describes in detail a number of the underlying system structures used and the 
facilities provided by the Accent kernel. Described in this chapter are: a) the process system, b) the 
memory system, c) the queuing system and d) the IPC system. 

The modules VMTypes.Pas and VMIPCTypes.Pas define most of the structures referenced 
here. 

2.1 Process System 

Accent provides for the concurrent execution of multiple processes. Each process in the system 
has a 2t32 byte address space. All address spaces are disjoint. 

The Accent scheduler provides a multiple priority scheduling system with preemption. The 
system provides 16 priority levels, with level zero being the lowest and level fifteen being the 
highest Scheduling is round robin within a priority level. In addition the scheduler implements an 
aging algorithm that is used to lower the priority of compute-bound processes. If at any time a 
process finishes its time quantum without blocking, the priority of that process is lowered. This 
lowering will happen each time the process completes a time slice without blocking. Thus it is 
possible for a process to move from priority fifteen to priority zero in sixteen time slices. The next 
time the process blocks, its priority is raised to its original level. To implement a degree of fairness, 
the time quantum is made larger as the priority level decreases. This system provides rapid 
response to highly interactive processes. 

The process management system interacts with the virtual memory management and 
inter-process communication systems to provide the execution environment for processes running 
on a host machine. 

All communication between a user process and the kernel is through a port, called its kernel 
port, which is created when the process is created. Since ports can be sent in messages to other 
processes, it is possible for process A to send its kernel port to process B. The process system is 
designed so that process B can manage process A's behavior, much the same way the virtual 
memory system allows one process to manage another's virtual memory. This mechanism forms the 
basis for remote debugging and monitoring systems. 
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2.1.1 Structures 

2.1.1.1 PCBHandlc (VMTypes.Pas) 

The PCBHandle provides all of the information about a process that must be available to the 
Accent microkernel. There is one PCB handle for each process in the system. The set of all 
PCBHandles is kept in a PCBTable, which is an array (LMaxProc of PCBHandles. This array is 
indexed using the process ID. 

Figure 1 gives the definition of the PCBHandle. 
PCBHandle = packed record 



NextEntry 


P roc ID; 


[ Word 0, 


16 bits 


} 


PrevEntry 


ProcID; 


[ Word 1, 


16 bits 


} 


QueuelD 


QID; 


[ Word 2, 


6 bits " 


MsgPending 


boolean; 


[ Word 2, 


1 bit ; 




EMsgPending 


boolean ; 


( Word 2, 


1 bit : 




InUse 


boolean ; 


{ Word 2, 


1 bit : 




SVCEntry 


boolean ; 


[ Word 2, 


1 bit : 




LimitSet 


boolean ; 


{ Word 2, 


1 bit ' 




SVStklnCore 


boolean ; 


{ Word 2, 


1 bit " 




Priority 


PriorlD; 


[ Word 2, 


4 bits : 




MsgEnable 


boolean; 


{ Word 3, 


1 bit : 




EMsgEnable 


boolean; 


{ Word 3, 


1 bit : 




F i 113 


0. .16383; 


( Word 3. 


14 bits" 


} 


SVStkPtr 


ptrMicroContext; 


[ Words 4, 


5 } 


SleepID 


ptrlnteger; 


{ Words 6, 


7 } 




RunTime 


. Bit32; 


{ Words 8,9 } 




LimitTime 


: Bit32; 


{ Words 10,11 } 




SleepTime 


. Bit32; 


{ Words 12,13 > 




SPMPtr 


: ptrSPM 


{ Word 14,15 } 





end; 



ptrPCBTable = tPCBTable; 

PCBTable = array [0 . .MAXPROCS] of PCBHandle; 
2.1.1.2 MicroContext(VMTypes.Pas) 

The MicroContext is used to hold information about a process when that process does not have 
control of the CPU. It holds the saved registers for the process as well as the EStk (contents of the 
hardware's expression stack) for the process. Figure 2 gives the definition of the MicroContext 

MicroContext = packed record 



EStk : array [0..15] of integer; 

Reg : array [0..63] of integer; 

Filll : array [1..32] of integer; 

TrapCode : integer; 

TrapArgs : Vi rtual Address ; 

EStkCnt : integer; 

State : ProcState; 

F i 1 1 2 : Bitl4; 

RegCnt : integer; 

Fill3 : array [1..8] of integer; 
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F i 1 1 4 
BPC 



Bit8; 
Bit4; 
Bit4; 



F1115 
F i 1 1 6 



integer 



end; 



2.2 Memory System 



This section describes in detail the way in which memory is addressed in the Accent system. 
The section is broken into two parts. 

The first part describes the way in which a process does addressing. It describes all of the 
structures that make up the memory map for a process and how those structures are accessed using 
, a process virtual address. 

The second part describes the way that the system translates a virtual address supplied by a 
process into an address in physical memory or into a page fault. 

2.2.1 Process address space 

2.2.1.1 Virtual memory management 

In Accent virtual memory, file storage and IPC are integrated together in a way that preserves 
the logical structure of inter-process communication while providing significant performance 
advantages over previous communication-based operating systems. This same melding of virtual 
memory with IPC makes it possible for Accent to allow one process to manage the virtual address 
space of another (either by allocating virtual memory from the kernel and sending it to another 
process or by explicitly managing page faults) and in so doing provides a clean, kernel-transparent 
mechanism for cross-network paging. 

2.11.2 Virtual memory and files 

The virtual address space of an Accent process is flat and linearly addressable. On the PERQ 
this address space is 2t32 sixteen bit words. An Accent segment is the basic unit of virtual memory 
allocation and secondary storage management. All randomly accessible secondary storage is 
considered part of the virtual memory of the system and is organized into Accent segments and 
managed by the kernel. 

There are two kinds of Accent segments: temporary and permanent Temporary segments are 
allocated by processes as required for their memory needs and are released when all processes 
which have access to them are terminated. The storage contained in permanent segments form the 
basis for the Accent file system. Permanent segments are allocated by sending messages to a special 
port normally supplied only to special processes. They do not disappear except by explicit request. 

Normally, new segments are allocated by the kernel in response to a CreateSegment message, 
with the kernel responding in a message with the newly created segment's identifier. A segment can 
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be explicitly destroyed through the use of a DcstroyScgmcnt message. The data contained in a 
segment can be read into a process's virtual address space using a ReadScgmcnt message. The reply 
to a ReadScgmcnt message contains the newly allocated pages which are mapped into the 
requesting process's address space through reception of the message. Similarly, data can be 
explicidy transferred out of a process's address space through the use of a WriteScgment message. 

2.2.1.3 Process directed management of virtual memory and network paging 

An advantage of the Accent approach to virtual memory is that it allows virtual memory to be 
considered a process-provided resource. A process can create an imaginary segment and "read" it 
into an unused part of its address space. It is then possible for a process to send" another process 
these 'imaginary pages' in a message. When the message is received, these pages are placed into the 
address map of the receiving process. When these pages are referenced by the receiving process, 
messages requesting their contents are sent to a port belonging to the process which created the 
segment. When a changed 'imaginary page' is about to be purged from main memory, its new 
contents are also sent in a message. This allows a process which is not the kernel to provide 
kernel-like management of secondary storage. In particular, it makes cross-network paging possible 
using the standard IPC facility. 

2.2.1.4 Virtual address make-up 

As indicated earlier, a virtual address under Accent is a 32 bit value. This value is made up a of 
a number of fields that are used during the translation process. This section will give a brief 
overview of those fields. 

Bit 31 of the virtual address is the Supervisor/User bit. If the bit is set the process is currently 
executing in supervisor space. If the bit is clear the process is running in user space. 

Bits 30 through 24 are used to pick one of 128 level 2 blocks. This value is used as an index into 
the Lev2 field of the process control block. 

Bits 23 through 16 are used as an index into the specific level 2 block. 

Bits 15 through 8 are used to pick a single page from a list of Spice Chunk Descriptors. 

Bits 7 through 0 are used to pick a single word in a page. 

2.2.1.5 Structures 

This section describes the data structures that define the virtual address space of a process. 
These structures are searched when a page fault occurs. They are not used for addressing when the 
desired page is in memory. There is a set of system tables that is used by the kernel to provide 
addressing when no faults are going to be taken (see Section 2.2.2). The tables provide much faster 
access to the required page than could be obtained by searching the three-level process map. 
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2.2.1.6 Spice Process Map (VMTypcs.Pas) 

The Spice Process Map, SPM, is the starting point for the translation of a process virtual 
address into a physical address. The SPM is pointed to by a field in the PCBHandle for the process. 

The F field is used to link a set of free SPMs. SCDFreeList is used to keep a list of free Spice 
Chunk Descriptors, (more about the SCDs later). MapBlks is a virtual address in the kernel virtual 
address space. It is the address of the start of the Map Blocks for this process. Map Blocks are a set 
of pages that are used to hold information about the process address mapping. Any single page in 
the set of pages that make up the map blocks holds a single type of information. A single map 
block can hold either Spice Chunk Descriptors or SCDIndices. The set of pages that make up the 
process map blocks are contiguous in kernel virtual address space. This implies that given the start 
address of the map blocks, simple address arithmetic can be done to get to a given map block. The 
Lev2 portion of the SPM holds a number of Lev2Indices. 

SPM = packed record 
F 

SCDFreeList 
Proc 
MapBlks 
MapSize 
NextBlk 
Lev2Size 
NextFree 
EndFree 
Lev2 
end; 



ptrSPM; 

SCDIndex; 

ProcessNumber; 

Vi rtualAddress ; 

long; 

Bit8; 

Bit8; 

VirtualAddress; 

Vi rtualAddress; { Next allocated - 1 } 
array [0..127] of Lev2Index 



2.11.7 Lev2Index (VMTypes.Pas) 

Each of these indices points to a map block that holds SCDIndices. 

A Lev2 index is picked by bits 30-24 of the process virtual address. This number is used as an 
index into the Lev2 array in the SPM. It is possible for a process to validate a 32 mega-word portion 
of virtual address space by making a single entry in the Lev2 portion of the SPM. No other 
structures need to be created until a portion of the address spaces is referenced. 

The Blk field of the Lev2Index picks a map block that contains a set of SCDIndices. 

The WriteProtect and the CopyOnWrite fields in the Lev2Index provide the protection on the 
entire portion of the process virtual address space. 

Lev2Index = packed record 

Blk : BU7; 

InUse : boolean; 

Free : boolean; 

case integer of 
1: 

( 

WriteProtect : boolean; 
CopyOnWrite : boolean; 
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Val id 



); 



StatusBits 



); 



3: ( 



ProtectBits 



boolean 



B i t-3 



Bit2 



end; 



) 



2.2.1.8 SCDIndcx (VMTypcs.Pas) 

The Lev2Block is the second level in the translation map. There are a number of SCDIndiccs in 
each map block. Bits 23-16 of the virtual address pick a specific SCDIndex. Once again it is possible 
for a process to validate a 128k byte portion of address space by simply creating a single SCDIndex. 

The WritcProtect and CopyOnWrite fields of the SCDIndex provide the protection information 
for that portion of the address space. 

The Blk field picks the map block that contains an SCD. The Blkindex picks a particular SCD 
in that map block. 



SCDIndex 



= packed record 

case integer of 



1: 



( 



3: 



Blk 

Blkindex 
WriteProtect 
CopyOnWrite 
Valid 



Index 

StatusBits 



Blank 

ProtectBits 



All 



end; 



) 



Bit7; 

Bit6; 

boolean; 

boolean; 

boolean 



Bitl3; 
Bit3 



Bitl3; 
Bit2 



integer 



2.2.1.9 SCD (VMTypes.pas) 

The SCD describes a "chunk" of the process's virtual address space. Each SCD describes a 
variable size portion of the address space of a process. The smallest portion described is a single 
page. The largest portion described is 256 pages. 

A larger portion of virtual address space is described by linking together a number of SCDs. 
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Bits 15-8 of the virtual address are used to pick the SCD that describes the pages containing the 
page picked by these bits. 

The SegmentPtr points to a structure called the Active Segment Table. This is a system-wide 
table that describes all of the currently active segments. SCDs for a number of different processes 
may point to the same AST entry. This allows the system to keep a single physical copy of a 
segment while allowing the different processes to see what they think are different copies of that 
segment. 

If a process changes a page that is shared by other processes, the process that changed the page 
must get a new copy of it. This is done by the Shadow Segment facilities described later. 



SCD 



= packed record 
StartPage : 
EndPage : 
SegmentPtr : 
SegmentOf f set : 
case integer of 
1: ( 

SCDNext 

): 
2: ( 

Blank 

WriteProtect 

CopyOnWrite 

Blankl 

); 

3: ( 

Blank2 

ProtectBits 

Blank3 

) 

end; 



B i t8 ; 
Bit8; 

ptrASTRecord; 
integer; 



SCDIndex 



Bitl3; 
boolean; 
boolean ; 
Bitl 



Bitl3; 

Bit2; 

Bitl 



111.10 AST(VMTypes.Pas) 

The Active Segment Record is used to describe a memory segment that is being accessed by 
one or more processes. The set of all active segments is kept in the Active Segment Table. This is a 
system-wide table. 

If a process changes a page of a segment, the system will assure that the process is the only one 
that sees the change. This is accomplished using the shadow segment facilities. A new segment, a 
shadow, is created. This segment is described by the SCD that was used to gain access to the page 
that was changed. The ShadowOf field of the new segment points to the AST record of the original 
segment. The IndexPtr points to the index blocks for the new shadow segment. There will be a 
valid index block for the pages of the shadow that have been changed. Pages that have not been 
changed have Index Blocks that contain a null value. When a reference is made to one of these 
non-changed pages that are described by the shadow, the system will follow the ShadowOf field to 
the original segment. The original segment will contain the desired page. This process allows the 
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system to reduce the number of copies of pages that are kept, while still maintaining the "no shared 
memory" semantics of the system. 



ASTRecord 



packed 
case 
1: 



record 

integer 

( 



of 



ShadowOf 
SegmentID 
UseCount 
SegKind 
case 



integer of 
( PhysSize 
( ImagID 
( SegOffset 



ptrASTRecord; 
ptrASTRecord; 
SegID; 
Bitl3; 

SpiceSegKind; 



0. . MEMPAGES-1 ); 
0. . MAXIMAG-1 ); 
integer) 



end; 



IndexPtr 
Blank 

Of f setlnPagingArea 
SizelnPagingArea 



IndexAddr 



ptrlndexBlock; 
ptrASTRecord; 
Bitl6; 
Bitl6 



DiskAddr 



2.2.2 System addressing 

This section describes the set of system tables that is used by the kernel to provide addressing 
when no faults are going to be taken. 

112.1 PVRecord 

The PVRecord is used to maintain information about the physical memory pages in the system. 
There is a single PVRecord for each page in physical memory. When a memory request is made the 
PVRecord for the page that contains the memory location is checked to see if the request is a valid 
one. 

A second important feature provided by the PVTable is that it maintains a list of all process 

virtual addresses that point to a physical page. This is used when a page is to be removed from 

physical memory. When the page is removed all virtual addresses that point to that physical page 

must be removed from the VPTable (see section 2.2.2.2). The PVList field of the PVRecord is an 

index into a second table maintained by the pager process. 

PVRecord = packed record 

WriteProtect : boolean; 

CopyOnWrite : boolean; 

Used : boolean; 

Dirty : boolean; 
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MappedToDisk 
Free 
Locked 
DontTouch 
HeaderChanged 
Swapln 
SwapOut 
InStack 
SVStkFlag 
UseCnt 
Flush 
PVList 
end; 



boolean ; 
boolean; 
boolean; 
boolean; 
boolean; 
boolean ; 
boolean; 
boolean ; 
boo! ean ; 
Bit2; 
boolean ; 
VPIndex 



ptrPV 
PV 



= tPV; 

= array [0 . .MEMPAGES-1] of PVRecord; 



2.12.2 VPRecord 

The VPTable is used to map a process virtual address into a system physical address. The 
VPTable is made up of a set of VPRecords. When a process presents a virtual address, the kernel 
translates that virtual address into a physical address or into a page fault. The VPTable is the data 
structure used during that translation. 

When an address request is made, a hash is computed using the virtual address and the process 
ID. The hash table used is the VPTable. The size of the hash table is determined by the number of 
physical pages in memory. In general there are about twice the number of hash entries in the table 
as there are physical pages in the memory. Hash collisions are chained together using the VPnext 
field in the VPRecord. The VA/ProcID pair is used as input into the hash function. The function 
returns an index into the VPTable. If the VA and ProcID presented to the hash match the VAddr 
and Proc in the VPRecord, then the VPRecord provides the desired physical address. If they do not 
match, the chain of VPRecord, linked on VPNext, is searched. If no match is found, the requested 
page is not in memory and the process will be forced to take a page fault 

VPRecord = packed record 

integer of 



case 
1: 



( 
) 

2: ( 



VAddr 
PAddr 

Proc 

Blankl 

Blank2 

WriteProtect 

CopyOnWrite 

Used 

Di rty 

InUse 

MappedToDisk 
InPl ace 
EndOfVPList 



VirtualAddress; 
PhysicalAddress 

ProcessNumber; 

Bit8; 

Bitl6; 

boolean; 

bool ean ; 

boolean; 

boolean; 

boolean; 

bool ean ; 

bool ean ; 

boolean; 
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PLsw 
PMsw 
VPNext 

): 

( VPFreeList 
StatusBits 

) 



: Bit8; 
: Bit4; 

: ShortVPIndex 

: PageList; 
: integer 



2.3 Queue System 



The queue system is used to provide process queueing. It is a very simple system. A process 
must be on one and only one queue at any given time. The set of all queues is kept by the kernel. 
Figure 11 gives the definition of the system queue tables. 

The meaning of each queue in the queue table is defined by a set of constants in VMTypes.Pas 
(see Figure 12). 



Queue 



ptrQueueTabl e 
QueueTabl e 

NUMSLEEPQS 
QNIL 

Front = 
Back = 

All 

One = 

NUMQUEUES 

RUNQS 



PENDINGQ 

SLEEPQ 

KILLQ 

FREEQ 



record 

QHead 

QTail 

TimeSl ice 

Filler 
end; 



ProcID; 
ProcID; 
integer; 
integer 



— 'T'QuOUSTflblQ" 

= array [0 . .NUMQUEUES] of Queue; 

32; ■ { must be power of two } 

0; { Nil Process ID or Nil QueuelD} 

true; • 

false; 

true; 
false; 

NUMSLEEPQS + NUMPRIORITIES + 6; 

1; { Run Queues } 

{ One for each priority } 

{ PCB locked in real memory } 

RUNQS + NUMPRIORITIES; { Pending Queue } 
{ Either timeslice end } 
{ or PCB not in real memory } 

PENDINGQ + 1; { Sleep Queues } 

{ Blocked on SleepID } 

SLEEPQ +' NUMSLEEPQS; 

{ Process termination queue } 

KILLQ +1; { Unallocated process queue } 
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LIMITQ = FREEQ +1; { Queue for processes which 

{ have exceeded time limit } 

SVCWAITQ = LIMITQ +1; { Waiting on Supervisor busy } 

2.4 IPC System 

Although processes are the active components of the system, the notion of process is a poor one 
on which to base a communication facility. Different languages may define multiple concurrent 
tasks within a single kernel-supported process. Moreover, a given service may be provided over a 
period of time by a number of different processes. 

The basic transport abstraction of the IPC is the notion of a port. A port is a protected kernel 
object into which messages may be placed by processes and from which messages may be removed. 
All services and facilities provided by a process are made available to other processes through one 
or more ports. 

Ports are intended to be used by processes to represent specific services or data structures. For 
example, a file system process might associate a separate port with each open file, or a virtual 
terminal handling process might allocate a port to represent each virtual terminal. However, no 
restriction is placed on their use. Ports may be used by processes to communicate information iff 
any mutually convenient way. 

Logically associated with each port is a queue on which resides messages sent to that port but 
not yet removed from it by a process. The ability to remove messages from a port is called receive 
access. Only one process may have receive access to a port at a time, although receive access to a 
port may be transferred to another process in a message. 

Ports cannot be directly manipulated or named by a process. Instead, the kernel provides 
processes with a secure capability to send a message to a port and/or receive a message from it. This 
capability is a local name for a system object, much in the way a UNIX software file descriptor is a 
local name for a system maintained file, pipe, or device UNIX. Port capabilities may be passed in 
messages, handed down to process children, or destroyed. A given process may have only one local 
name for a given port at a time. Whenever a port name is passed in a message the system kernel 
must map that name from the local name space of the sending process into the name space of the 
receiving process. 

The ability to manipulate access to ports allows for the redirection of communication from one 
process to another and the explicit management of communication between two processes by a 
third process. It also allows a port to be used to refer to a specific service or process-provided object 
even in situations in which that service or object is handled by different servers at different times. 
Neither the address (i.e. the location) nor the name of a process can be determined from the 
capability to send a message to one of its ports. 
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2.4.1 Creating, accessing and destroying ports 

A port is created by a process through an AllocatePort system call. It is a system object, distinct 
from the process which created it but initially owned by the creating process. The result of the 
AllocatePort call is a local port name which refers to the created port. 

Initially the owner of a port also has receive access to it. Ownership of a port and receive access 
are, however, logically distinct Ownership of a port may be passed in a message from one process 
to another, but not shared. Receive access to a port may also be passed in a message but not shared. 
These restrictions prevent multiple servers from managing the same queue, and are necessary to 
avoid serious problems which occur when access to a single queue is shared by processes on 
different machines. 

If a single process both owns and has receive access to a port, that process may destroy the port 
by performing a DeallocatcPort system call. A process with a capability (local name) to a port may 
release the capability via the same system call. 

A port is automatically destroyed when its owner and the process with receive access to it both 
die. In either case, all processes with access to that port arc notified via emergency messages. If the 
same process does not both own and have receive access to a port, then the deallocation of the port 
name by either process results in an emergency error message being sent to the other accompanied 
by full access rights to that port (i.e., both ownership and receive rights). 

The purpose of distinguishing receive access from ownership is to allow a process to take over 
services or functions provided by other processes in the event those processes should die or 
malfunction. This is particularly important when writing fail-soft software and can also be used to 
provide orderly shut-down of services after catastrophic failures. 

2.4.2 Software or pseudo interrupts 

In the case where a process does not wish to wait for messages explicitly, it is possible to enable 
a software interrupt which will be triggered upon message reception. The interrupt service routine, 
executing in the context of that process, can then receive the incoming message and process it or 
notify the main program of the event in a user-defined manner. A mechanism such as this can 
allow processes which are inherently compute-bound to react quickly to incoming messages 
without using some form of message polling. 

143 Flow control 

The message queues attached to ports have a finite length. This prevents a sending process from 
queueing more messages to a receiving process than can be absorbed by the system and provides a 
means for controlling the flow of data between processes of mismatched processing speed. 

Subject to implementation restrictions on maximum port size, the process owning a port is 
allowed to specify its backlog-the maximum number of normal messages which may be queued for 
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that port at one time. Should a process attempt to send a message to a full port, one of three things 
may happen depending on options specified by the sender: 
The process is suspended until the message can be placed in the queue. 

The process is notified of an error condition (after perhaps allowing itself to be suspended for up 
to a specific period of time waiting for the message to be sent). 

The message is accepted and the kernel sends a message to the sending process when that 
message can actually be placed in the queue. A maximum of one message per sending process 
per receiving port may be outstanding in this fashion. 

These three options correspond to three different programming situations: 

The first option is the one most likely to be used by a 'user 
process' when communicating with a 'server process.' In this 
situation the user process docs not care if it is suspended for 
some time waiting for a message to be delivered to the server 
(as in the case of a remote procedure call). 

The second option is used when a process does not care whether 
" a particular message is sent to a destination, but is using the 
the message only to wake up a dormant partner. The fact that 
other messages are in the queue for the partner's port indicates 
that the partner is already scheduled to be activated. 

The third option is the one most likely to be used by a service 
process when dealing with a user process. The server probably 
cannot afford to be suspended waiting on a user to clear its 
queue. It may also not want to just throw away the message or 
poll the user explicitly until the message can be sent. The 
system provides an explicit message event corresponding to the 
unblocking of the user's port queue. 

14.4 Waiting for messages 

Although particular protocols may specify synchronous behavior, the receipt of a message is 
inherently an asynchronous event In a network environment, in particular, it becomes possible for 
error conditions to cause messages to be sent to a process at almost any time. Mechanisms must 
therefore be provided for a process to check the state of its ports, to wait for activity on one or more 
of its ports, and to receive messages selectively. It should also be possible for a process to specify a 
maximum amount of time to wait for a message before reawakening. 

Four basic primitives are provided for accomplishing this task. 

Receive(SetOfPorts,Message,Timeout) waits for at most Timeout milliseconds and if a message is 
available during that time from any of the ports designated by SetOfPorts then the message is 
read into Message and a boolean value of true is returned. 
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• McssageWait(SctOfPorts,Timcout) performs a similar function, but docs not receive the pending 
message. It returns the capability of the port from which the next message would be received. 

• Prcvicw(SctOfPorts,Mcssage,Timeout) is again similar to Receive, but it reads only the header of 
the next waiting message and docs not actually dequeue that message from the port queue. 

• PortsWitliMessagcsWaiting(SetOfPorts) is an informational routine which checks the status of all 
ports and returns the set of ports with messages waiting. 

2.4.5 Sending and receiving kernel messages 

Each newly created process has access to two ports whose primary purpose is to allow messages 
to be sent to and received from the Accent kernel. The first is called the kernel port of the process, 
and the kernel logically has the receive rights for this port while the created process has the send 
rights. The second is called the data port, and it is normally used by a process to receive messages 
from the kernel. 

The parent of a process can, at the time of process creation, ask that other ports to which it has 
access be given to its child process. The parent can also get access to the kernel and data port of the 
child process. This, taken together with the ability to send port access rights in messages, is the 
basic mechanism for establishing communication between processes. 

2.4.6 Messages 

A message is logically a collection of typed data objects copied from the address space of the 
sender at the time of a message send call into the address space of the receiver when a receive call is 
performed. Physically, a message is divided into two parts: 1) the message header, which contains 
information normally associated with all messages and 2) an optional description of structured data 
to be sent The purpose of this division is primarily to optimize the transmission of short control 
messages and to make it easier for the kernel to find critical information which must always be 
contained in a message-such as its destination port 

2.4.7 The message header 

The message header contains a small amount of system required message information and is 
used to form an anchor for the structured part of a message. At minimum it specifies the message 
type and contains a capability for the destination port of a message and a field for a capability 
(which may be empty) to be used for a reply. The destination and reply ports are more commonly 
referred to as the remote and local ports, respectively. The header also contains an ID field to be 
used for discriminating messages and a pointer to the structured data part of the message. 

The header may be checked without actually receiving the data portion of a message by calling 
Preview. The purpose of this facility is to allow a process to check the ID of the message being 
received and select an appropriate message structure for receiving it 
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The message type contains information which determines the kind of service it requires of the 
IPC. Two types have been given special names and play a dominate role in communication: 

Normal messages A 'normal' message is flow controlled, sequential, reliable, not secure, of lowest 
priority, and has no maximum age. This is the default message type and is 
assumed to satisfy most communication requirements. 

Emergency messages Emergency messages are specially flow controlled, sequential, 

reliable, not secure, of highest priority, and have no maximum age. Emergency ■ 
messages play an important role in error handling. Because of their high priority, 
they arc guaranteed to be received before any normal messages arc sent to a port. 
Their purpose is to allow urgent information to be delivered to a process 
regardless of that process's current message backlog or message queue. They are 
used for error notification, special event processing, and debugging. 

The notion of message type allows the programmer the ability to specify the exact requirements 
of his IPC use. This gives the underlying system more information about a message and thus makes 
possible optimizations in the delivery and management of messages. This use of message types is 
consistent with the overall goal of making as much of the inner workings of the communication 
system as possible visible to the 'outside world' rather than hidden inside compiled algorithms, thus 
allowing greater flexibility in optimization, management, and monitoring. 

14.8 Exceptional condition handling 

Distributed programming imposes a heavy responsibility to handle a multitude of error 
conditions. Message activity can be pipelined or multiplexed, and the relationships between 
incoming and outgoing messages can be much richer than in a conventional programming 
environment (i.e., one in which subroutines are used as the primary structuring mechanism). A 
faulty process could conceivably crash many processes by sending illegal messages, making it very 
hard to identify the source of the problem. As a practical matter, it is difficult to ensure complete 
compatibility between similar programs written by different individuals in different languages. 
Supposedly interchangeable processes may differ in subtle ways. A failure in a message-based 
system can quickly lead to finger-pointing. 

A variety of facilities for protection, error detection, and error handling has been built into the 
IPC. Illegal process addresses are noted within the send and receive primitives, and the appropriate 
error returned to the offending process. In addition, processes are protected from accidental or 
malicious access through the use of port capabilities rather than global port or process identifiers. 
Whenever a port is destroyed the kernel notifies all processes which still have access to that port via 
an emergency message. Emergency messages themselves are important because they give processes 
a way to reliably communicate errors in situations where normal communication channels are 
blocked. Software interrupts allow processes to handle error conditions without interfering with 
normal execution. 
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2.4.9 Optimizing message transfers 

Messages are logically copied from a process's address space into a kernel message data 
structure upon transmission and arc logically copied from the kernel to a process's address space 
upon message reception. Since data is never shared between processes, message communication 
over a network has precisely the same semantics as local message communication. 

Double copy semantics need not, however, imply actually copying the data twice. If a process 
sends a message pointing to pages in its virtual memory and either releases the memory or simply 
never changes it, double copy semantics can be preserved by marking the pages referenced in the 
message as copy-on-write and not actually copying them into the supervisor's address space. 
Moreover, if the receiver of the message doesn't care about its placement or desires that it be placed 
in its memory on the same page boundaries, no copy of data need be performed at all. Instead, the 
data pages may be placed directly into the address map of the receiving process. 

Thus, when a process sends a message to a port, whole virtual memory pages referenced in the 
message are not copied but instead marked as copy-on-write in the address space of the sender. 
Should the sender attempt to change any or all of these pages, new virtual pages will be allocated, 
filled with the appropriate data, and placed in its address space. On reception into an area of the 
receiver's virtual memory which is properly aligned, pages referred to in the incoming message are 
mapped in rather than copied. If the receiver desires a different alignment of data than that 
specified by the sender, a copy operation will be performed. 

The utilization of virtual memory by the IPC represents a functionally transparent optimization 
which is not required either for the functioning of the IPC or the virtual memory management 
facility. Nevertheless, this optimization can be of enormous value in increasing the speed of 
communication between processes on the same host 

Example: 

The advantage of integrating virtual memory, file storage, and IPC is graphically illustrated by 
the example of file system access provided through messages sent to and from a file system process. 
The file system process can read secondary storage by sending a message to the kernel. The kernel 
then sends back a message which contains the virtual pages requested by the file system. This 
message need look no different than any other message containing data. Moreover the requested 
pages need never be copied, but are simply placed into the address space of the file system in the 
normal way that data is placed into the address space of any process when received in a message. If 
a user requests a block of data, however large, the file system can send it that block in a message, 
again without ever having the underlying data referenced by either the kernel or the file system. In 
this way the speed advantages of large memory mapped files can be obtained through the reception 
of normal IPC messages without resorting to special file mapping primitives. 
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2.4.10 IPC and port structures. 

This section describes the structures that arc used by the IPC sytstem. 
2.4.10.1 Port structures 

Figure 13 gives the definition of the structure that is used to define an IPC port. There is a 
single PortRec for each port in the system. The record keeps all information needed by the IPC 
system on a per port basis. 

It is interesting to note that the queue of messages for a port are not kept with the port. That 
queue is kept in the per process IPCRecord (see Section 2.4.10.2). 

The SccondaryMsgQ is used to hold a single message. This is the message that can be sent to a 
port when that port is full. When a process puts a message into this queue, the sending process will 
be notified when it is possible to place that message into its standard queue. 

The Senders field of the record contains a bit array that has a bit for each process in the system. 
If a process has send access to the port, the bit in the Senders field that corresponds to the 
ProcessID of the sending process will be set. 



PortRec - record 

SecondaryMsgQ 
NumQueued 
Backlog 
Owner 
Receiver 
Locked 
InUse 
Senders 
RectanglePtr 
end; 



ptrKMsg ; 

integer; 

integer; 

ProcID; 

ProcID; 

boolean ; 

boolean; 

ProcBitArray; 

ptrRectangle 



14.10.2 Process IPC structures 

For each process in the system there is a per-process table that is used by the IPC system. This 
table contains information about the IPC state for that process. 

All messages for a process are linked using a field in the IPCRecord. In general the number of 
messages that are waiting for a process to receive at any given time is small. In addition to this fact, 
most receives are done on the set of all ports to which the process has receive access. Based on these 
two facts there is a performance improvement to be had by linking the message with the process. 
When a process does a receive, the system need only look at the process IPC table. The system does 
not have to search the list of ports to which this process has receive access. 

The DebugPort is a field that contains a port on which the system can send a message if this 
process dies. The Limit and Wait ports are ports on which the system can send a message to notify 
some process that something unusual has happened to this process. 

MsgsWaiting is a pointer to the first message in a linked list of messages for this process. 
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KPort contains the Kernel and Data ports for the process. 



IPCRecord = 



record 
Active 
State 
DebugPort 
MsgsWaiting 
PreviewMsg 
LimitPort 
WaitOption 
WaitPt 

UseHashTable 
KPorts 
end; 



boolean; 
IPCState; 
Port; 
ptrKMsg ; 
ptrKMsg ; 
Port; 
integer; 
Port; 
bool ean ; 

array [KERNELPORT, 



, DATAPORT] of Port 



ptrlPCRecord = tiPCRecord; 



ptrlPCInfo = tlPCInfo; 

IPCInfo = array[KERNELPROC . .NPROC+1] of IPCRecord; 
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Part Three 
Major Subsystems 

This chapter gives an overview of the major subsystems that make up the Accent operating 
system. Each major subsystem, except the Message Server, is discussed in more detail in its own 
document in this manual. 

Accent is structured as a set of cooperating processes. All requests arc made by building a 
message and sending that message to a server request port. 

This method of making requests is used throughout the operating system. Even requests of the 
Kernel are made by building a message and executing a Send. The Send code will look at the 
message to determine the port to which the message is to go. If the port is the kernel port of the 
process, the send is turned into the correct Kernel trap for the requested function. 

For details on how to make use of these servers, see the documents on the specific server or the 
Programming Examples portion of this document. 

For the name of ports that provide most of these functions, see Appendix B. 

For system defined server ports, see Appendix D. 

3.1 Kernel 

The kernel of the Accent operating system provides the virtual machine on which Accent 
processes execute. The kernel is implemented in a combination of microcode and Pascal. In theory 
the only functions that must be provided by the kernel are the primitive IPC facilities. For 
performance reasons a number of other facilities are currently provided by the kernel. 

The kernel provides the following interfaces to the Accent virtual machine: 

1. IPC System facilities. 

2. allocation and deallocation of ports 
changing port backlog 
interposing a port for another port 
send and receive primitives 

control of software interrupts 1 associated with the IPC system. 

3. Process control facilities: 

4. Fork 
Terminate 
Priority 
Setting limits 
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Suspend and resume process execution 
5. Memory management facilities: 
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Reading and writing of process Stack and register sets 
Reading and wridng of process virtual memory space. 

7. Segment control facilities: 

8. Create, Destroy and Truncate segment 

Read and Write Segments to and from backing store 

9. Backing store control and status 

10. Get information about the disks 
Mount and DisMount disk partitions 
Direct Disk I/O operations 

11. Display operations 

12. RasterOp 
Line 

DrawByte 

The interfaces to the kernel provided facilities are found in AccentUser and AccCall in 
LibPascal. 

3.2 File System 

Accent provides a single level store view of the memory hieriarchy. In the Accent system there 
is only virtual memory. Some of that virtual memory can reside on disk and have a name. This long 
term storage of virtual memory is the responsibility of the file system. When a file is to be read, a 
request is made to the file system to provide that file. The file system will arrange to have the entire 
file mapped into the requester's address space. There are no actual data transfers that occur during 
this operation. Only mapping operations are performed. When the process touches a piece of the 
data, the page that contains the data is brought into memory using the normal page fault facilities. 
When a file is to be written to disk, it is first created in virtual memory. The client process then asks 
the file system to save that piece of virtual memory on the disk with a specific name. 

The file system provides access to files that are on the local disk. In addition, it provides access 
to files that may reside on other disks that are attached to other machines on the network. When a 
request is made for a file that does not reside on the local machine, the file system does a number of 
operations. First it must look to see if it has ever accessed a file on the remote machine before. If so, 
it will have access to a port that is the request port for the remote machine. If this is the first access, 
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the file system must try to find the desired machine. It does this by doing a simple IPC look up of 
the remote file access port for that machine. Once the port is obtained, the request is made for the 
file. If the desired file is small, the entire file is sent to the requesting machine in a single message. If 
the file is large the remote machine sends an IOU for the data. Segments of this type are called 
imaginary segments. They are a piece of memory that is backed by another process. When the local 
process touches a page of the imaginary segment, a request is made to the remote machine for the 
desired page. 

A client of the file system does not need to know if a file is on a local disk or on a remote disk. 
All operations on the file are accomplished in the same manner. 

The direct interfaces to the file system in ScsUser.Pas are very low level. The module 
PathName.Pas provides a much more user-oriented interface to the filing system. This is the 
. recommended interface for users of the file system. 

3.3 Window Manager 

The Window Manager provides the facilities that are used to place text and graphics on the 
screen and to obtain input from users. These facilities are provided by a set of three different 
processes. These processes act in close cooperation to provide the user oriented input/output 
facilities of the system. 

The Window system is made up of three different abstractions. They are: 

• Windows - Windows are a user abstraction. They are the objects that the user deals with on the 
screen. Windows can be moved to different locations on the screen in all three dimensions. 
Windows can be uncovered, partially covered, completely covered, or off screen. In addition to a 
virtual display the window also provides a control point for a process or a group of processes. The 
Window Manager provides process group control operations that can be invoked on the processes 
that are associated with a window. The icons provided by the system describe the state of 
windows and of the processes associated with those windows. 

• ViewPorts - ViewPorts are abstractions that are presented to clients of the window manager. A 
ViewPort is the output portion of a window. In general most windows are made up of two 
viewports. One viewport (the "outer" viewport) covers the entire area of the window, including 
its borders and title line. The second viewport is the client usable area of the window. This 
viewport is usually called the "inner viewport" 

• TypeScripts - TypeScripts are the input abstractions that are presented to the clients of the 
window. 
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3.3.1 General 

The Window Manager is the process that handles the window and display system. It supports a 
full implementation of covered windows. The Window Manager also provides additional facilities 
through the use of Icons. 

The Icon window is controlled by the Window Manager. Clients of the Window Manager can 
make requests for changes to be made to the Icon that is associated with that client 

3.3.2 TypeScript 

The TypeScript manager maintains standard text windows (Typescripts), providing line editing 
and redisplay functions for user programs that do not require graphics output or elaborate input 
control. 

TypeScript remembers the last several pages (a window's worth) of text output by the program 
using a typescript. When a text window changes state, size or coveredness, TypeScript will 
redisplay to changed portion of the window. TypeScript will also redisplay information that may 
have scrolled from the window. 

TypeScript allows the user to edit input lines using a subset of the commands available in the 
system editor. The user can use all of the editor's single-line editing functions, and recall previous 
input lines to be edited into new input lines. 

TypeScript also handles Escape Completion for each typescript The user may type a partial 
filename and press the Escape key; TypeScript will ask the file system to complete the file name by 
finding the longest unambiguous match tothe partial name. It will then add the name to the line of 
input so that the user can specify the rest of the name or add more to the line. 

TypeScript can either stop at the end of each screenful of output (Tnore' mode) or scroll output 
continuously. The user can select which mode to use, under keyboard control. 

In 'More' mode, when a full page of output has been displayed, a black bar appears at the 
bottom of the window. The user then presses LineFeed to display the next page of output 

In continuous scroll mode, the user can use the Process Control Functions Suspend and 
Resume to stop or start output 

333 Tracker 

Tracker is the process that actually listens to the keyboard and the tablet. It receives data from 
these input devices and then routes that data to the appropriate process. In addition it is Tracker 
that keeps the cursor tracking the puck or mouse. 
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3.4 Environment Manager 

The Environment Manager provides processes with an execution environment. This 
environment can include any number of user and system defined variables. Environment Manager 
variables can be of two types: a) simple strings or b) searchlists. 

It is possible for a client of the Environment Manager to set an environment variable and then 
to later obtain the value of that variable. In addition it is possible to ask the Environment Manager 
to make the environment variable known to other processes in the system. 

Environment variables can be defined as simple strings or they can be defined in terms of other 
environment variables. 

The client interface to the Environment Manager is in EnvMgrUserPas in LibPascal. 

3.5 Net Server 

The Network Server is the process that is responsible for driving the Ethernet hardware. It 
provides facilities that allow multiple client processes to use the network concurrently. The client 
interface to the Net Server is found in two files: NetlOMBUser and NetlOMBRecvServer in 
LibPascal. 

3.6 Message Server 

The Message Server is the process that is responsible for extending the IPC facilities across the 
network. In addition the Message Server provides a simple name service facility. 

3.6.1 Name service 

The only client interface to the Message Server is for using the Naming Services. The client 
interface to the name server portions of the message server are found in the file MsgNUser.Pas in 
LibPascal. 

The interface to the Name Server is very simple: 
1. A process can register a port with a given name. 
1 A process can request the port associated with a name. 

3. A process can destroy the name/port connection. In addition a call is provided to return status 
information associated with a port 
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3.6.2 Network IPC operation 

The major function provided by the Message Server is to extend the IPC system across the 
network. An example wiil be used to show the manner in which this is done. 

3.6.2.1 Finding a name 

1. Process A on Machine A executes a LookUp. The Look Up is for a port provided by Process B on 
Machine B. 

2. The Message Server on Machine A notices that it does not have an entry for Process B in its name 
space. 

3. The Message Server on Machine A sends a broadcast message on the network asking all other 
message servers if they have an entry for name B. 

4. The Message Server on Machine B receives the message and determines that it does have an 
entry for name B. 

5. It will reply to the request from Message Server A saying "I have a port for B. Here is an ID that 
you can use to talk to me about B." 

6. The Message Server on Machine A receives the message from the Message Server on B. It then 
allocates a port, A', that it associates with the ID provided by the Message Server on Machine B. 

7. Finally the message server on Machine A returns the port A' to Process A. 

Note that Process A does not know that the port A' is a port to the Message Server and not to 
Process B. The fact that Process B is on another machine is transparent to Process A. 

- 3.6.12 Sending a message 

1. Process A wants to send a message to Process B. It executes a Send command using Port A' as the 
destination. 

2. Message Server A receives the message on port A'. It looks in its internal tables and notices that 
port A' is associated with a process on another machine. 

3. Message Server A sends the message, using some network protocol, to Message Server B. 

4. Message Server B looks at the ID provided by Message Server A and finds the port on Machine B 
that is associated with that ID. 

5. Message Server B then sends the message to Process B on the port that Process B supplied during 
a Checkln command. 

3.6.2.3 Deleting ports 

When a remote port is deleted, the following actions take place: 

1. The owner of the Port B deletes it. 

2. The Message Server B gets a Port Death message. 

3. Message Server B sends a message to Message Server A, telling it that Port B has died. 

4. Message Server A deletes the port A'. 
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5. Process A gets a Port died message for Port A'. The semantics of the Port Deleted processing is 
exactly the same as if the port were on the local machine. This is because, in fact, it is a local port 
that is deleted. 

3.7 Time Server 

The Time Server provides all of the time of day facilities provided by the operating system. It 
can return the time and date in a number of different formats. The interface to this server is found 
in the file TimcUser.Pas in LibPascal. 

3.8 I/O System 

The I/O system provides access to all I/O devices except the disk and the network. There is a 
single standard interface to all of the devices. The way in which a client picks the device to be 
accessed is by sending the requests to the appropriate server. There is one server for each of the 
supported I/O devices. The interface to the I/O servers is found in IOUser.Pas in LibPascal. 
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Part Four 
Accent Environments 



Accent provides a number of environments for the user of the system. Each of the 
environments provides its own user interface, command line processing, error processing, and style 
of operation. All of the environments make use of the virtual machine provided by the Accent 
kernel. In addition, all of the environments make use of the input and output facilities provided by 
the Accent window manager. 

Any number of these environments may by active at any given time. In addition, it is possible , 
for processes running in one environment to communicate with processes in other environments 
using the Accent IPC facilities. 

At the current time Accent provides its user with three different environments. They are: a) 
Native Accent, b) UNIX System V, and c) Accent Lisp. 

4.1 Native Accent Environment 

The native Accent environment is started when the operating system is booted. The user 
interface to this environment is the Accent Shell. This Shell provides command processing, as well 
as a number of simple commands, for the Accent environment. Most commands used in this 
environment are interactive. 

4.2 UNIX System V 

The UNIX System V environment is provided by the Qnix system. Qnix is an emulator that 
provides a UNIX System V system call interface. This interface allows most UNIX software 
programs to be ported to run on the PERQ workstation by simply recompiling the source. 

The user interface to the Qnix system is provided by the UNIX software shell. This provides a 
well known environment to a large number of users. There are very few differences between the 
Qnix environment and the environment provided by UNIX System V. 

It is possible to run native Accent programs from the Qnix environment in the same manner as 
running Qnix programs. The only limitation is that it is not possible to pipe between the two 
environments. 

To start the Qnix environment execute the command file QnixInitCmd. 

4.3 AI Workstation 
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The AI workstation environment is provided by running Accent Lisp on the machine. Accent 
Lisp is a superset of Common Lisp. 

Lisp is a programming language widely used for Artificial Intelligence research. It was 
conceived by John McCarthy in 1958. Because of its built-in facilities for symbol-processing and its 
interactive programming environment, the language is increasingly being used for such 
applications as compilers, CAD systems, and editors. 

Common Lisp is a new dialect of Lisp, closely related to MacLisp, Lisp Machine Lisp 
(Zetalisp), and (somewhat less closely) Franz Lisp. It was developed jointly by several Lisp groups 
to meet the need for a modern Lisp dialect that is stable, well-documented, and suitable for 
implementation on a variety of machines. 

Accent Lisp is the implementation of the Common Lisp language for the PERQ workstation. It 
was developed by the Spice Lisp Group at Carnegie-Mellon University; it is nearly identical to the 
Common Lisp implementations on VAX/VMS and VAX/Unix. 

The Accent Lisp release includes Hemlock, an editor written in Common Lisp. It is based on 
TOPS-20 EMACS, an editor written by Richard M. Stallman of the Massachusetts Institute of 
Technology. 
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Part Five 
Programming Examples 



This chapter gives a number of example programs. These programs, in general, do not do 
anything useful. They do however show how to use a number of the facilities of the Accent 
operating system. 

5.1 Messages 

Below are two programs that send and receive IPC messages. 

The first program, Messagel, sends and receives both simple and complex messages. The 
program performs the following functions: 

1. Define types that can be used for messages. 

2. Allocate ports. 

3. Register a port/name pair with the name server. 

4. Present a name to the name server and receive a port. 

5. Send a simple message. 

6. Receive a simple message. 

7. Send a complex message. 

8. Receive a complex message. 

The second program, Message2, is slightly different than Messagel. In Messagc2 the program 
will be interrupted when a message arrives. The program will not do a receive until the message is 
there. This method of interaction allows the program to perform other computations while waiting 
for a message. 

Generally, programs do not do actual IPC sends and receives. Most interprocess interaction is 
done using Remote Procedure Call interfaces that were generated by Matchmaker. In these cases it 
is the Matchmaker code that does the sends and receives. Using Matchmaker interfaces is the 
preferred way of doing multiple process programs, 
program Messagel; 

{ Abstract: 

{ This program demonstrates the use of the message system. 

{ It will send and receive both "simple" and "complex" messages. 

{ Written by: Don Scelza 

{ Copyright (C) PERQ Systems Corp., 1984 
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imports 


Pascal Init 


f rom 


Pascal Init; 






{Many 


imports 


MsgN 


from 


MsgNUser ; 


imports 


AccCall 


f rom 


AccCal 1 ; 


imports 


Acclnt 


f rom 


AccentUser; 


imports 


AccentType 


from 


AccentType; 


imports 


SaltError 


from 


Sal tError; 


imports 


CommandDef s 


from 


CommandDef s 


type 









{For access to the 

{name server} 

{For Send and Receive} 

{AllocatePort} 

{GR values} 

{Error routines} 

{Get the value for ErAnyError} 



DataArray = array[0..10] of integer; 
pDataArray = tDataArray; 

A message has the following form: 

1) There is a message header. This defines the entire message 
to the system. 

2) The header is followed by zero or more objects. An object is 
made up of two parts. 

a) A descriptor. This defines all of the information 
about a single object. 

b) The data for the object. 



MySimpleMessage = record 
Head: msg; 

MType: TypeType; 
Data: DataArray; 
end; 



{ A simple message does not contain } 

{ any ports or pointers to "out of } 

{ line" data. } 

{ A descriptor for "Data"} 

{ The actual data to be passed. } 



pMySimpleMessage = tMySimpleMessage; 

MyComplexMessage = record { A complex message may contain ports} 

Head: msg; { or "out of line" data. In this 

case} 

{ the } 

MType: TypeType; { may have to translate the Ports or } 

Data: pDataArray; { make new memory map entries for the} 

end; { out of line data } 

pMyComplexMessage = tMyComplexMessage; 



var 



MyPort: Port; 
MsgExamplePort: Port; 



{ We will do receives on this port.} 
{ We will do sends on this port. } 
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const 

MyName = 'MsgExample ' ; { Just a name to use } 

PortBackLog = 3; 

{ Number of messages that may be queued on a port } 

Simplelndex = 12345; { An id for a simple message } 

Complexlndex = 54321; { An id for a complex message } 



procedure RegisterName; 

{ — — " " " } 

{ Abstract: 

{ Register a named port with the Name Server. 
{ Design: 

{ The port that we will register is MyPort. It is 
{ assumed that MyPort is a valid port at the time that 
{ this procedure is called. It is also assumed that the 
{ interface, to the NameServer has been initialized. 

{ - " } 

var Gr: General Return ; 

begin 

write! n( ' Register ', MyName, ' with the name server.'}; 

Gr := CheckIn(NameServerPort,{ NameServer from Pascallnit } 
MyName, { The name for this port} 

NullPort, { Not used currently. Must be 

Null Port) 

MyPort); { The port to give to others } 

if Gr <> Success then 
begin 

GRWriteStdError(Gr, GR_Fatal Error , 'Could not "Checkln"*); 
end; 

end; 

procedure LookUpMyName; 



Abstract: 

Lookup the port name MyName. Place the port returned 
by the NameServer into MsgExamplePort. 



var Gr: General Return ; 
begin 

writeln( 'Lookup MyName, ' from the name server.'); 

Gr := LookL)p(NameServerPort, { NameServer from Pascallnit } 

MyName, { The name that we want to find.} 

MsgExamplePort); { Will hold the desired port } 

if Gr <> Success then 
beg in 

GRWriteStdError(Gr, GR_Fatal Error , 'Could not "LookUp" ' ) ; 
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end ; 

end ; 

procedure AllocateMyPort; 



Abstract: 

This procedure is used to allocate a new port. The port 
that is allocated will be placed into MyPort. 



var Gr: General Return ; 
begin 

writel n( 'Allocate port.'); 

Gr := AllocatePort(Kernelport, {My port to the Kernel } 

MyPort, {Put the new port in MyPort } 

PortBackLog ) ; {Allow this many messages to be 

queued} 

if Gr <> Success then 
begin 

GRWriteStdError(Gr , GR_FatalError, 'Could not allocate 
MyPort'); 

end; 

end; 

procedure SendSimple; 



Abstract: 

Set-up and send a simple message on port MsgExampl ePort 



var Gr: GeneralReturn; 

SendMyP: pMySimpl eMessage ; 
I: integer; 

begin 

writeln( 'Send a simple message.'); 

new(SendMyP) ; " { Allocate the message } 

{ 

{ First set up the message header. This describes the entire message 
{ that is to be sent. 

{} 

with SendMyPt.Head do 
begin 

SimpleMsg := true; 

{ This is a simple message. No ports or pointers } 
MsgType := NormalMsg; 

{ This is a normal, not emergancy, message. } 
LocalPort := NullPort; 

{ The port for a reply. We don't expect to get one.} 
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RemotePort := MyPort; 

{ Destination for the message } 
ID := Simplelndex; 

{ An ID that the receiver can check } 
MsgSize := wordsize(MySimp1 eMessage) * 2; 
end; 

{ 

{ Now set up the object descriptor for the data of the message. 
{} 



with SendMyPi- .MType do 
beg in 

TypeName := TypeUnStructured;{ Just bits. No ports or 
pointers} 

NumObjects : = 1; { Only one object in the 

message} 

InLine := true; { The data is in the message. No 

pointers} 

LongForm := false; { This is a simple description } 
Deallocate := false; 

{ Don't remove the message from the senders address 

space} 

TypeSizelnBits := wordsize(DataArray) * 18; 
end; 

{ 

{ Put in some values for the data. 
O 

with SendMyPt do 
begin 

for I := 0 to 10 do Data[I] := I + 23; 
end; 

{ 

{ Now send the message 
{} 

Gr := Send(SendMyPt .Head, { The message header } 
0, { Don't time out } 

Wait); { Wait for it to finish } 

if Gr <> Success then 
beg in 

GRWriteStdError(Gr, GR_Fatal Error, 'Could not Send 
Simpl eMessage' ) ; 
end; 

dispose(SendHyP) ; 
end; 
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procedure SendComplex; 

{" 
{ 



r a i j. . - 



{ Set-up and send a Complex message on port MsgExampl ePort 

{-- 

var Gr: General Return ; 

SendMyP: pMyCompl exMessage ; 
DataP: pDataArray; 
I: integer; 

begin 

writeln( 'Send a complex message.'); 

new(SendMyP) ; { Allocate the message } 

new(DataP); { Allocate the data memory } 

{ First set up. the message header. This describes the entire message 

{ that is to be sent, 

{> 

with SendMyPt .Head do 
begin 

SimpleMsg : = false; { This is a complex message. } 

MsgType := NormalMsg; { This is a normal message. } 

LocalPort := NullPort; 

{ The port for a reply. We don't expect to get one. } 
RemotePort := MyPort; { Destination for the message } 

ID := Complexlndex; { An ID that the receiver can 

check} 

MsgSize := wordsize(MyComplexMessage) * 2; 
end; 

{ Now set up the object descriptor for the data of the message. 
O 

with SendMyPt. MType do 
begin 

TypeName := TypeUnStructured; { Just bits. No ports or 
pointers} 

NumObjects := 1; { Only one object in the 

message} 

InLine : = false; { The data is referenced by a 

pointer} 

LongForm := false; { This is a simple description} 

Deallocate := false; 

{ Dw'fawve the message from the senders address 

space} 

TypeSizelnBits := wordsize(pointer) * 16; 
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end; 

{ 

{ Put in some values for the data. 
{} 

for I := 0 to 10 do DataPt[l] : = I + 23; 
SendMyPt.Data := DataP; 

{ 

{ Now send the message 
{} 

Gr := Send(SendMyPt.Head, { The message header } 
0, { Don't time out } 

Wait); { Wait for it to finish } 

if Gr <> Success then 
begin 

GRWriteStdError(Gr, GR_Fatal Error , 'Could not Send 
ComplexMessage' ) ; 
end; 

dispose(SendMyP) ; 
dispose(DataP) ; 
end; 

procedure ReceiveSimpleMsg ; 



Abstract: 

This procedure will receive a message. It will check the 
ID of the message to see if it was one that was expected. 



var Gr: GeneralReturn; 

SimpleP: pMySimpleMessage; 
begin 

writeln( 'Receive a simple message.'); 
new(SimpleP) ; 

SimplePt.Head.MsgSize := wordsize(MySimpleMessage) * 2; 
Gr := Receive(SimplePi'.Head, { Receive the message into 
SimpleP. } 

0, { Don't time out. Just wait. } 

AllPts, { Receive any messages on any 

ports. } 

Receivelt); { Actually receive the message. } 

if Gr <> Success then 
begin 

GRWriteStdError(Gr, GR_Fatal Error , 

'Could not receive a simple message.'); 
end; 

if SimplePt.Head.ID <> Simplelndex then 
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begin 

GRWriteStdError(ErAny Error, GR_Fata1 Error, 
'Message was not a simple message. '); 
end; 

end ; 

procedure ReceiveComplexMsg; 

{ " "} 

{ Abstract: 

{ This procedure will receive a message. It will check the 
{ ID of the message to see if it was one that was expected. 

{ - "} 

var Gr: General Return ; 

ComplexP: pMyComplexMessage; 
begin 

writel n( ' Receive a complex message.'); 
new( Compl exP) ; 

ComplexPt.Head.MsgSize := words ize(MySimpl eMessage) * 2; 
Gr := Receive(ComplexPt.Head, { Receive the message into 
ComplexP.} 

0, { Don't time out. Just wait. } 

ALlPts, { Receive any messages on any 

ports .} 

Receivelt); { Actually receive the message. } 

if Gr <> Success then 
begin 

GRWriteStdError(Gr , GR_Fatal Error , 

'Could not receive a complex message.'); 
end; 

if Compl exPt. Head. ID <> Complexlndex then 
begin 

GRWriteStdError(ErAnyError, GR_Fatal Error, 
'Message was not a complex message. '); 
end; 

end; 



begin 



{ 

{ Allocate a new -port. Register that port with the NameServer. 

{ LookUp the port and get the Send rights to it. 

{ 

{ Actually we already have all of the rights to the port. 

{ In addition the values of MyPort and MsgExampl ePort will be the 

{ same because this is a single process. If the call to LookUpMyName 

{ was in a different process the values of MyPort and MsgExamplePort 

{ might be different. In that case the process that did the LookUp- 
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{ MyName would have send rights to MsgExampl ePort . It would not 

{ have receive rights to it. 

{} 

Al locateMyPort; 

RegisterName; 

LookllpMyName; 

{ 

{ Send a simple message 
O 

SendSimple; 

<■ ■ 

{ Receive a message. We know that there is one there because 

{ we just sent it. 

{} 

ReceiveSimpleMsg ; 
{ 

{ Send a complex message 
{> 

SendComplex; 

{ Receive a message. We know that there is one there because 

{ we just sent it. 

{} 



ReceiveComplexMsg; 
end. 

program Message2; 



- — - > 

Abstract: 

This program demonstrates the use of the message system. 

It will send and receive a simple message using the software 

interrupt facility to be notified when a message is available. 

Written by: Don Scelza 

Copyright (C) PERQ Systems Corp., 1984 



imports Pascal Init from Pascal Init; 

{ Many useful ports are defined 

here.}' 



25 Aug 84 



Theory of Operations - 44 



imports MsgN 
server } 
imports AccCall 
imports Acclnt 
imports AccentType 
imports SaltError 
imports CommandDefs 
ErAnyError. } 
imports Except 



type 



from MsgNUser; { For access to the name 

from AccCall; { For Send and Receive } 

from AccentUser; { AllocatePort } 

from AccentType; { GR values } 

from SaltError; { Error routines } 

from CommandDefs; { Get the value for 



from Except; 



{ For Message exceptions } 



DataArray = array[0..10] of integer; 



A message has the following form: 

1) There is a message header. This defines the entire message 
to the system. 

2) The header is followed by zero or more objects. An object is 
made up of two parts. 

a) A descriptor. This defines all of the information 
about a single object. 

b) The data for the object. 



MySimpleMessage = record 
any } 

Head: msg; 

data} 

MType: TypeType; 
Data: DataArray; 
end; 



{ A simple message does not contain 

{ ports or pointers to "out of line" 

{ A descriptor for "Data"} 

{ The actual data to be passed. } 



pMySimpleMessage = tMySimpleMessage; 



var 



MyPort: 

MsgExamplePort; 
NoMessage : 
BoolDum: 
Gr: 



Port; 



{ We will do receives on this port. 



Port; { We will do sends on this port. } 
boolean; { True if waiting for a message } 
boolean; { A dummy } 
GeneralReturn; 



const 

My Name 



'MsgExample ' ; { Just a name to use } 
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PortBackLog = 3; 

{ Number of messages that may be queued on a port } 
Simplelndex = 12345; " {An id for a simple message 

} 

procedure RegisterName; 



{ Abstract: 

{ Register a named port with the Name Server. 
{ Design: 

{ The port that we will register is MyPort. It is 
{ assumed that MyPort is a valid port at the time that 
{ this procedure is called. It is also assumed that the 
{ interface to the NameServer has been initialized. 

{ } 

var Gr: General Return ; 

begin 

writeln( 'Register ', MyName, ' with the name server.'); ■ 
Gr i- Checkl n ( NamsSe rve rPort , •£ NameServer from Pascal Init } 
MyName, { The name for this port} 

NullPort, { Not used currently. Must be 

Null Port} 

MyPort); { The port to give to others } 

if Gr <> Success then 
begin 

GRWriteStdError(Gr, GR_Fatal Error , 'Could not "Checkln"'); 
end; 

end; 

procedure LookUpMyName; 



{ Abstract: 

{ Lookup the port name MyName. Place the port returned 
{ by the NameServer into MsgExamplePort. 

{ - - " " -} 

var Gr: GeneralReturn; 
begin 

writeln( 'Lookup ', MyName, ' from the name server.'); 

Gr := LookUp(NameServerPort, { NameServer from Pascallnit } 

MyName, { The name that we want to find. } 

MsgExamplePort); { Will hold the desired port } 

if Gr <> Success then 
begin 

GRWriteStdError(Gr, GR_FatalError, 'Could not "LookUp*"); 
end; 

end; 

procedure Al locateMyPort; 
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i 

{ Abstract: 

I* Th "i r n nAitnijnnn { n i ■ r* n ri + « aIIaaa-I-a *• _ . . . ~ A. 'T I . - i 

j_ mi 10 pi uv,cuui c i o u o c u T.u ai lut/dLC a new purl.. I lie pun. 

{ that is allocated will be placed into MyPort. 
{ 

{ — — } 

var Gr: GeneralReturn; 

begin 

writeln( 'Allocate port.'); 

Gr := AllocatePort(Kernelport, { My port to the Kernel } 

MyPort, { Put the new port in MyPort } 
PortBackLog) ;{ Allow this many messages to be 

queued} 

if Gr <> Success then 
begin 

GRWriteStdError(Gr , GR_FatalError, 'Could not allocate 
MyPort'); 

end; . 

end; 

procedure SendSimple; 



Abstract: 

Set-up and send a simple message on port MsgExamplePort 



var Gr: GeneralReturn; 

SendMyP: pMySimpleMessage; 
I: integer; 

begin 

writeln( 'Send a simple message.'); 

new(SendMyP); { Allocate the message } 

{ 

{ First set up the message header. This describes the entire message 
{ that is to be sent. 

{} 

with SendMyPt.Head do 
begin 

SimpleMsg := true; { This is a simple message. No ports or 
pointers} 

MsgType := EmergencyMsg ; { Send an Emergency message to be 
different.} 

LocalPort := NullPort; 

{ The port for a reply. We don't expect to get 

one.} 

RemotePort := MyPort; { Destination for the message } 

ID := Simplelndex; { An ID that the receiver can 
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check} 

MsgSize := wordsize(MySimpleMessage) * 2; 
end; 

{ 

{ Now set up the object descriptor for the data of the message. 
{> 

with SendMyPt .MType do 
begin 

TypeName := TypeUnStructured; { Just bits. Mo ports or 
pointers} 

NumObjects := 1; { Only one object in the 

message } 

InLine := true; { The data is in the message. No 

pointers} 

LongForm := false; { This is a simple description 

} 

Deallocate := false; 

{ Don't remove the message from the senders address 

space} 

TypeSizelnBits := wordsize(DataArray) * 16; 
end; 

{ 

{ Put in some values for the data. 
{} 

with SendMyPt do 
begin 

for I := 0 to 10 do Data[I] : = I + 23; 
end; 

{ 

{ Now send the message 
{> 

Gr := Send(SendMyPi\Head, { The message header } 

0, { Don't time out } 

Wait); { Wait for it to finish } 

if Gr <> Success then 
begin 

GRWriteStdError(Gr, GR_FatalError, 'Could not Send 
SimpleMessage ' ) ; 
end; 

dispose(SendMyP) ; 
end; 

procedure ReceiveSimpleMsg; 



25 Aug 84 



Theory of Operations - 48 



{ Abstract: 

{ This procedure will receive a message. It will check the 
{ ID of the message to see if it was one that was expected. 



r 
i. 

{ " 

var Gr: General Return ; 

SimpleP: pMySimpleMessage; 

begin 

write! n( ' Receive a simple message.'); 
new(SimpleP) ; 

SimplePt.Head.MsgSize := wordsize(MySimpleMessage) * 2; 
Gr := Receive(SimplePt.Head, { Receive the message into 
SimpleP.} 

0, { Don't time out. Just wait. } 

AllPts, { Receive any messages on any 

ports .} 

Receivelt); { Actually receive the message, 

if Gr <> Success then 
begin 

GRWriteStdEr.ror(Gr , GR_Fatal Error , 

'Could not receive a simple message.'); 
end; 

if SimplePt.Head. ID <> Simplelndex then 
beg in 

GRWri teStdError(ErAny Error, GR_Fatal Error , 
'Message was not a simple message. '); 
end; 

end; 

handler EmergMsg; 



Abstract: 

This handler will be called when an emergency message is 
received. 



begin 

writel n( 1 Enter message exception handler.'); 
ReceiveSimpl eMsg ; 
NoMessage := false; 
end; 



begin 
{ 

{ Allocate a new port. Register that port with the NameServer. 

{ LookUp the port and get the Send rights to it. 

{ 

{ Actually we already have all of the rights to the port. 
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{ In addition the values of MyPort and MsgExampl ePort will be the 
same 

{ because this is a single process. If the. call to LookUpMyName was 
in 

{ a different process the values of MyPort and MsgExampl ePort might 
be 

{ different. In that case the process that did the LookUpMyName 
would 

{ have send rights to MsgExamplePort. It would not have receive 

{ rights to it. 

O 

AllocateMyPort; 

RegisterName; 

LookUpMyName; 

NoMessage := true; 
{ 

{ Tell the system to interrupt the process when an emergency message 
{ is received. When the message is ready an exception is raised. 

ri 
\J 

BoolDum := true; 

Gr : = Sof tInterrupt(Kernel Port, { Send the request to the 

Kernel } 

false, { Allow exceptions on emergency 

messages} 

BoolDum); { Turn them on. Return the old value in 

BoolDum} 



{ 

{ Send a simple message 
{} 

SendSimple; 

{ Now process until a message arrives. 
{} 

while NoMessage do ; 
end. 



5.2 Matchmaker 

Matchmaker is a language for defining remote procedure calls. Remote procedure calls are 
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message-based interfaces with declarations. These interfaces are generally between multiple 
processes in a multiple-language programming environment. Once an interface between two 
processes has been declared, then Matchmaker can be used to generate procedures for sending and 
receiving messages. Both processes can understand the messages even though the processes may be 
written in different languages. Matchmaker does all the work of appropriately packing the 
procedure arguments into messages and extracting message fields for incoming procedure 
arguments. 

Matchmaker allows a programmer to write a server process and declare the types of all data to 
be exchanged between the server and its user processes. Procedural interfaces can be declared 
based on those types for sending data between processes in messages. When these procedures are 
implemented they can begin to send and receive messages, rather than code within the same 
process. Remote procedure call interfaces simplify and increase the reliability of writing message 
based code. 

Examples are given in the document "Matchmaker: The Accent Remote Procedure Call 
Language". 



This section provides two simple graphics programs. 

The first, Graphics!., performs some simple graphics operations. It draws lines and does 
rasterops. 

The second program, Graphics2, shows how to enable and deal with notification that the size or 
coveredness of a window has changed, 
program Graphicsl; 



Abstract: 

This program demonstrates some simple uses of the window 
manager. The program does all operations in the window 
from which it was started. This program will NOT handle 
any of the emergency messages that the window manager 
provides to the client when a viewport changes. 

Written by: Don Scelza 

Copyright (C) PERQ Systems Corp., 1984 



5.3 Graphics 



} 



imports Pascallnit 



from Pascallnit; 



imports AccentType 
imports SaltError 



{ Many useful ports are defined here. } 
from AccentType; { GR values } 
from SaltError; { Error routines } 
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imports CommandDefs from CommandDef s ; { Get the value for 
ErAnyError} 

{ 

{ Get the interface to the Window Manager. 
O 

imports ViewPt from ViewPtUser; 

imports Sapph from SapphUser; 

imports ViewKern from ViewKern; 

imports WindowUtils from WindowUtil s; 

var 

MaxX: integer; { Max X coordinate } 

MaxY: integer; { Max Y coordinate } 

VP: ViewPort; { Inner ViewPort of the user window.} 

procedure GetViewPortlnfo; 



_ - } 

Abstract: 

Get the information needed to draw in the current window. 
UserWindow is a variable in Pascallnit. It is the window that 
the program was run in. From this we can get the information 
about the inner viewport of that window. This information 
includes: 

VP: The InnerVierPort 

MaxX: The MaxX point of the inner viewport. 
MaxY: The MaxY point of the inner viewport. 



begin 

WindowViewPort(UserWindow, VP, MaxX, MaxY); 
end; 

procedure Clear; 



Abstract: 

This procedure will clear the inner viewport of the 
user window. 



begin 

VPColorRect(VP, RectWhite, 0, 0, MaxX, MaxY); 
end; 

procedure WaitForCr; 



Abstract: 

Set the window attention flag and wait for a <cr>. 
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var S: string; 
. begin 

ShowWindowAt tefi t ~\ On Fl ay ; { Turn 00 the "!". } 

readl n(S) ; 

RemoveWindowAttentionFl ag ; 
end; 

procedure DrawLines; 



Abstract: 

Draw a set of rectangles. One inside the other. 



var StartX, StartY, EndX, EndY: integer; 
Done: boolean; 

beg in 

Done := false; 
StartX := 0; 
StartY := 0; 
EndX : = MaxX; 
EndY := MaxY; 
while not Done do 
begin 

VPLine(VP, DrawLine, StartX, StartY, EndX. StartY); 
VPLine(VP, DrawLine, StartX, EndY, EndX, EndY); 
VPLine(VP, DrawLine, StartX, StartY, StartX, EndY); 
VPLine(VP, DrawLine, EndX, StartY, EndX, EndY); 
StartX := StartX +4; 
StartY := StartY + 4; ' 
EndX := EndX - 4; 
EndY := EndY - 4; 

if (StartX >= EndX) or (StartY >= EndY) then Done := true; 
end; 

end; 

procedure RasterOps; 



Abstract: 

This procedure will do a set of rasterops. The 
algorithm is the same as DrawLines. 



var StartX, StartY, EndX, EndY: integer; 
Done: boolean; 



begin 

Done := false; 
StartX := 0; 
StartY := 0; 
EndX := MaxX; " 
EndY := MaxY; 
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while not Done do 
begin 
VPRop(VP, 

RNot, 

StartX, 

StartY, 

EndX - StartX, 
EndY - StartY, 
VP, 

StartX, 

StartY); 
StartX := StartX + 4; 
StartY := StartY + 4; 
EndX := EndX - 4; 
EndY := EndY - 4; 
if (StartX >= EndX) or (StartY > 
end; 

end; 



{ Source ViewPort for the rasterop} 
{ Use a Not function } 
{ Start X and Y locations } 

{ width and height } 

{ Dest ViewPort for the rasterop} 
{ Start X and Y locations } 



EndY) then Done := true; 



begin 



GetViewPortlnfo; { Get the information about the 

viewport.} 

Clear; 

writeln( 'This is a simple graphics test program.'); 
writeln('It runs a set of tests and then waits for the user to'); 
writeln( 'Type a <cr>. When the attention flag in the window Icon'); 
writeln('is set type <cr> to go onto the next display.*); 

WaitForCr; 

Clear; { Clear the screen } 

DrawLines; { Draw some lines } 

WaitForCr; { Wait to go on. } 

Clear; 

RasterOps; 

WaitForCr; 

end. 

program Graphics2; 

{ - - — > 

{ Abstract: 

{ This program demonstrates some simple uses of the window 
{ manager. The program does all operations in the window 
{ from which it was started. 

{ This version of the program has the code needed to handle 
{ the messages from the window manager that signify changes 
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{ to the state of the window. 
{ 

{ Written by: Don Scelza 
{ 

{ Copyright (C) PERQ Systems Corp., 1984 
{ 

{ — ———— 



imports Pascal Init 

imports AccentType 
imports SaltError 
imports CommandDefs 
ErAnyError} 



from Pascal Init; 

{ Many useful ports defined here. } 

from AccentType; { GR values } 

from SaltError; { Error routines } 

from CommandDefs; { Get the value for 



.{ 

{ Get the interfaces needed to receive messages 
{} 



from Except; 
from AccCall ; 



imports Except 
imports AccCall 

{ 

{ Get the interface to the Window Manager. 
{} 



{ For Message exceptions} 
{ For Send and Receive } 



imports ViewPt 

imports Sapph 

imports ViewKern 

imports Windowlltils 



{ 



from ViewPtUser; 
from SapphUser; 
from ViewKern; 
from Windowlltils; 



{ Get the portions of the Window manager that deal with 
{ window state change notification. 
{} 

imports SaphEmrServer from SaphEmrServer ; 
imports SaphEmrExceptions from SaphEmrExceptions ; 



var 

MaxX: 
MaxY: 
VP: 
window.} 

BoolDum: 
Gr: 



integer; 
integer; 
ViewPort; 

boolean; 
General Return; 



{ Max X coordinate } 
{ May Y coordinate } 
{ Inner VierPort of the user 



procedure GetViewPortlnfo; 

{ " " — ■ 

{ Abstract: 

{ Get the information needed to draw in the current window. 

{ UserWindow is a variable in Pascallnit. It is the window that 



25 Aug 84 



Theory of Operations - 55 



the program was run in. From this we can get the information 
about the inner viewport of that window. This information 
includes : 

VP: The InnerVierPort 

MaxX: The MaxX point of the inner viewport. 
MaxY: The MaxY point of the inner viewport. 



begin 

WindowViewPort(UserWindow, VP, MaxX, MaxY); 
end; 

procedure Clear; 



Abstract: 

This procedure will clear the inner viewport of the 
user window. 



begin 

VPColorRect(VP, RectWhite, 0, 0, MaxX, MaxY); 
end; 



procedure WaitForCr; 

{ — > 

{ Abstract: 

{ Set the window attention flag and wait for a <cr>. 

{- — - > 

var S: string; 

begin 

ShowWindowAttentionFlag; { Turn on the "!". } 

readln(S) ; 

RemoveWindowAttentionFlag; 
end; 

procedure DrawLines; 

{ } 

{ Abstract: 

{ Draw a set of rectangles. One inside the other. 

{ — - > 

var StartX, StartY, EndX, EndY: integer; 
Done: boolean; 

begin 

Done := false; 
StartX := 0; 
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StartY := 0; 
EndX := MaxX; 
EndY := MaxY; 
while not Done do 
begin 

VPLine(VP, DrawLine, StartX, StartY, EndX, StartY); 
VPLine(VP, DrawLine, StartX, EndY, EndX, EndY); 
VPLine(VP, DrawLine, StartX, StartY, StartX, EndY); 
VPLine(VP, DrawLine, EndX, StartY, EndX, EndY); 
StartX := StartX + 4; 
StartY := StartY + 4; 
EndX := EndX - 4; 
EndY := EndY - 4; 

if (StartX >= EndX) or (StartY >= EndY) then Done := true; 
end ; 

end ; 

handler EmergMsg; 

{ > 



Abstract: 

This handler will be called when an emergency message is 
received. The code will receive the message and then pass 
it to the Client code of the Window Manager. If the message 
was a window manager message, the code will raise the 
correct exception for the type of change that happened to the 
window. 



{ - - > 

const MaxMsgSize = 2048; 

type space = array[0. .MaxMsgSize div 2 - 1] of integer; 
pDummyMsg = tDummyMsg; 
DummyMsg = record 

head: msg; 

RetType: typetype; 

RetCode: integer; 

body: space; 

end; 

var Gr: GeneralReturn; 
BDum: boolean; 
pReply, pMsg: pDummyMsg; 

begin 

{ 

{ Receive the message. 
{} 

new(pReply) ; 
new(pMsg) ; 

pMsgt.Head.MsgSize := MaxMsgSize * 2; 

Gr := Receive(pMsg*.Head, 0, AllPts, Receivelt); 
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{ Call the Window Manager. If the message was a Window Manager 
{ message an exception will be raised and the call will return 
{ true. If it was not a Window Manager message no exception 
{ will be raised and the call will return false. 
{} 

if SaphEmrServer(pMsg , pReply) then 
begin 
end; 

{ 

{ Turn on interrupts on messages receive again. 
{> 

dispose(pReply) ; 
dispose(pMsg) ; 
BDum := true; 

Gr := SoftInterrupt(Kerne1Port, false, BDum); 
end; 

handler EViewPtChanged(VP: ViewPort; XI, Yl, Wl , HI, R: integer); 
{ - } 

{ Abstract: 

{ This exception is raised if the size of the viewport changes. 
{ We will get the new size parameters and redisplay the lines. 



begin 

GetViewPortlnfo; 
Clear; 
DrawLines; 
end; 

handler EViewPtExposed(VP: ViewPort; RA: pRectArray; NUmRectangles: 
long); 



Abstract: 

This exception is raised if the coveredness of the 
viewport changes. 



begin 

GetViewPortlnfo; 
Clear; 
DrawLines; 
end; 



begin 
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{ is received. When the message is ready an exception is raised. 
{} 

BoolDum := true; 

Gr := SoftInterrupt(KernelPort, { Send the request to the Kernel } 
false, { Allow exceptions on emergency 

messages } 

-BoolDum); { Turn them on. Return the old value in 

BoolDum} 



GetViewPortlnfo; { Get the information about the viewport. 

Clear; 

{ 

{ Tell the window manager to generate exceptions when a 

{ window state change happens. 

{} 

EnableNotifyExceptions(VP, DataPort, true, true); 



writelnf 'This is a simple graphics test program.'); 
writeln('It will draw a display and wait for the user to type'); 
writeln{'a <cr>. While waiting, if the state of the window 
changes ' ) ; 

writeln('the display will be redrawn.'); 
WaitForCr; 



Clear; { Clear the screen } 

DrawLines; { Draw some lines } 

WaitForCr; { Wait to go on. } 



end. 



5.4 FileSystem 

The Accent file system presents a single level view of the memory hierarchy. Files are mapped 
into the process virtual address space. This means that access to portions of a file are the same as 
access to portions of memory. When a file is read the contents of that file are mapped into the 
address space. The file system returns a pointer that is the virtual address of the start of the data. It 
also supplies the number of bytes of data that were in the file. 
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Filel is a simple program that will read a file and treat the contents of that file as integers, 
program Filel; 



Abstract: 

This program demonstrates the use of the file system. 
Read a file and print the first 100 integers in it. 



Written by: Don Scelza 

Copyright (C) PERQ Systems Corp., 1984 



imports 


Pascal Init 


f rom 


here.} 






imports 


AccentType 


from 


imports 


Sal tError 


f rom 


imports 


CommandDef s 


f rom 


ErAnyEf ror.} 




imports 


PathName 


f rom 



{ Many useful ports are defined 

centType; { GR values } 

ItError; { Error routines } 
mmandDefs; { Get the value for 

thName; { High level interface to the 

^ {file sys. } 

type 

IntArray = array[0..0] of integer; { Used to access the file 
data} 

plntArray = tintArray; 



var ArrayPtr: 
I: 

FName: 
NumBytes: 
Lastlndex ; 
Gr: 



plntArray; 

integer; 

Path_Name; 

long; 

long; 

GeneralReturn; 



begin 

{ First map the file into our address space. 
{} 

FName := 'Filel. Pas'; 

Gr := ReadFile(FName, recast(ArrayPtr , File_Data), NumBytes); 
if Gr <> Success then 
begin 

GRWriteStdError(Gr, GR_Fatal Error , 'Filel. Pas'); 
end; 
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writeln( ' Ful 1 name of the file found is ', FName); 
{ 

f NOW TQQk ft +ho f 1 PC+ 1QQ UflllipC T-F f hara a r»o lac-* A f\f\ 

^ ■ - — V= 1 ^ w " «»• • ■ ■ w w jl v w * u ■ O ^ u . xi bilWI & Ul C I GO J Id 1 1 UN 1 

{ integers in the file only look at the ones that are there. 
{ 

{ We must turn off range checking to access the data using the 

defined 

{ type. 

{> 



if NumBytes > 200 then 
Lastlndex := 100 

else 

Lastlndex := shrink(NumBytes div 2); 
{$r-} 

for I := 1 to Lastlndex do 
write! n(ArrayPtrt[l]) • 
{$r=} 

end. 

There are two commonly desired changes to the above program that are simple to make in the 
Accent file system. The differences are: a) the use of a specific search list and b) having the system 
look for files with specific extensions. Both of these facilities are provided by the same system call. 

The call to ReadFile in the above example can be replaced by a call to the procedure 
ReadExtendedFile. This procedure allows the client to specify both a list of extensions and a 
specific search list 

The Extension list is specified as a string. It has the form: 

'<ext>;<ext>;...<ext>' 

You must remember that if a file without an extension is acceptable you must specify a null 
<ext> as the first value. To look for files that have a .Pas or a .Defs or no extension, the string that 
should be supplied is: 

';.Pas;.Defs' 

To specify a different search list you must supply the Environment Manager variable name that 
is the search list. The standard search list is named <Default>. 

5.5 Process Management 

This section provides a number of examples of creating and using processes. 
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The first program, ProcessSplit, docs a simple process split. After a split, one of the processes is 
the parent and the other process is the child. The two processes are exact copies of each other. The 
Split call returns an indication of which process is the parent and which process is the child. 

The second program, ProcessExcc, docs an Exec. The Exec system call starts a new process 
running a specific program. The new process is not a copy of the parent, as in Split This program 
will Exec a number of copies of itself. Each copy will allocate a port and register it with the name 
server. Because all of these processes are descendants of each other, they are all in the same process 
control group. To end the chain of Execs when a new copy of ProcessExcc finds a specific name, 
instead of doing another Exec that process will tell the process manager to kill the entire group of 
processes. 

program ProcessSplit; 



Abstract: 

This is a simple program that does a Split. After 
to spl it there will be two processes. One process 
parent while the other process will be the child. 



the 

wi 1 



call 
! be th< 



This program does a simple split and then both processes exit. 
If desired it is possible for the parent process to wait for the 
child to die. When the child dies the kernel will send a 
message to the parent on its data port. This will be an 
emergency message. 

Written by: Don Scelza 

Copyright (C) PERQ Systems Corp., 1984 



imports Pascal Init 
> 

imports AccCall 

imports AccentType 

imports SaltError 

imports CommandDefs 
ErAnyError} 

imports Spawn 



from Pascallnit; 

{ Many useful ports are defined here. 

from AccCall; { For Send and Receive } 

from AccentType; { GR values } 

from SaltError; { Error routines } 

from CommandDefs; { Get the value for 



from Spawn; 



{ For Split } 



var 

CKPort: 
CDPort: 
Gr: 



port; 
port; 

GeneralReturn; 



procedure IAmTheChild; 

{ 

{ Abstract: 
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{ This procedure will be executed by the Child process 
{ after the split. 

{ 

/ . 

begin 

write1n('I am the child'); 
end; 

procedure IAmTheParent ; 



Abstract : 

This procedure will be executed by the Parent process 
after the split. 



begin 

writeln('I am the parent'); 
end; 

begin 

Gr := Split(CKPort, CDPort); 
if Gr = IsChild then 
begin 

IAmTheChild; 
end 

else 

begin 

IAmTheParent; 
end; 

end. 

program ProcessExec; 



{ Abstract: 

{ This program does an Exec. It will Exec itself a number of 

{ times. Each time the new process will register its Data Port 

{ with the name server. The first process will register a name of 

{ "1". The second process will register a name of "2". Each time 

{ a process starts it will lookup these names. If the name "1" 

{ is not registered that process will register it. If the name 

{ is registered the process will go on to the next name. 

{ All of these processes will be in the same process control 
group. 

{ When a process starts and is able to find a port with the name 
{ "2" that process will kill the entire process group. 

{ Written by: Don Scelza 

{ Copyright (C) PERQ Systems Corp., 1984 

{ " } 
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imports Pascallnit 
} 

imports AccCall 
imports AccentType 
imports SaltError 
imports CommandDefs 
ErAnyError. } 
imports Spawn 
imports MsgN 
imports ProcMgr 
processes } 



from Pascallnit; 

{ Many useful ports are defined here, 

from AccCall; { For Send and Receive } 

from AccentType; { GR values } 

from SaltError; { Error routines > 

from CommandDefs; { Get the value for 

from Spawn; { For Split } 

from MsgNUser; { To register ports } 

from ProcMgrUser; { To kill this set of 



var 

CKPort: port; 

CDPort: port; 

Gr: General Return ; 

MyProcName: string; 

TestP: port; 

HisCommand: Command Block; 

type 

MySimpleMessage = record { A simple message does not contain any 

J Head: msg; { ports or pointers to "out of line" 
data} 

MType: TypeType; { A descriptor for "Data"} 

Data: integer; { The actual data to be passed. } 

end; 

pMySimpleMessage = tMySimpleMessage; 

function FindNextProcName: string; 



Abstract: 

This procedure will find the next name to register with 
the name server. The names that will be searched for are: 
n l" then "2" then "3". 



Results: 

Return the next name to be used. 

— - - — } 

var Gr: GeneralReturn; 
P: port; 

begin 

writeln( 'Looking for "1"'); 
Gr := Lookup (NameServerPort, '1', P) ; 
if Gr <> Success then 
begin 

FindNextProcName :='!'; 
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exit( FindNextProcName) ; 
end; 

write! n( ' Looking for "2"'); 
Gr := LookUp(NameServerPort, '2', P); 
if Gr <> Success then 
begin 

FindNextProcName := '2'; 
exit(FindNextProcName) ; 
end ; 

writel n( ' Looking for "3"'); 
Gr := LookUp(NameServerPort, '3', P); 
if Gr <> Success then 
begin 

FindNextProcName := '3'; 
ex it( FindNextProcName) ; 
end; 

end; 

procedure RegisterName(Who: string); 

f -— " — > 
{ Abstract: 

{ Register a named port with the Name Server. 
{ Parameters: 

{ Who is the name that we are to register. 
{ Design: 

{ The port that we will register is the TestP. 



var Gr: GeneralReturn; 
begin 

Gr := CheckIn(NameServerPort, Who. NullPort, TestP); 
if Gr <> Success then 
begin 

GRWriteStdError(Gr, GR_FatalError, 'Could not "Checkln"'); 
end; 

end; 

procedure All ocateMy Port; 



Abstract: 

This procedure is used to allocate a new port. The port 
that is allocated will be placed into TestP. 



var Gr: General Rett»«*r.-;. ■■■■■■■■ 
begin 
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Gr := AllocatePort(Kernelport, TestP, 1); 
if Gr <> Success then 
begin 

GRWriteStdError(Gr, GR_Fata!Error, 'Could not allocate 

TestP'); 

end; 

end ; 

■ 

procedure WaitToDie; 



Abstract: 

This procedure will wait for a message on our Test port. 
Because no process will ever send a message there, we will 
wait until a process group signal is generated. 



var Gr: General Return ; 

SimpleP: pMySimpl eMessage; 

begin 

new(SimpleP) ; 

SimplePt.Head.MsgSize := wordsize(MySimpleMessage) * 2; 
SimplePt.Head.LocalPort := TestP; 

{ We only want messages that are on 

TestP} 

Gr := Receive(SimplePt.Head, { Receive the message into 

SimpleP} 

0, { Don't time out. Just wait. } 

LocalPt, { Only messages on TestP } 

Receivelt); { Actually receive the message} 

if Gr <> Success then 
begin 

GRWriteStdError(Gr, GR_Fatal Error, 

'Could not receive a simple message.'}; 
end; 

end; 



begin 

writeln(*New process is looking for a name:'); 

MyProcName := FindNextProcName; { Look for the next name } 

writeln{'My name is ', MyProcName); 

AllocateMyPort; { Get the port to be registered. 

} 

if MyProcName = '3' then { "3" is the last name. Kill the 

group} 
beg i n 

writeln(MyProcName, ' is the last process. Killing the group 1 ); 
PMGroupSignal (PMPort, UserWindow, SigLevel lAbort) ; 
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end 

el se 

begin 

writeln( ' Register ', MyProcName, ' with the name server.'); 
RegisterName(MyProcName) ; 

write! n( ' Exec the next process.'); 

Gr := Exec(CKPort, CDPort, 'Exec. Run', HisCommand) ; 

writeln(MyProcName, ' is waiting to die.'); 

WaitToDie; 

end; 

end. 



5.6 Network 

All requests for network services go through the NetServer. This process provides the device 
driver for the network hardware. 

The example network program is a simple process that will perform network time service. 
When a time request is received on the network, this process will get the time from its local time 
server and respond with a network packet to the machine that made the request, 
program NetTimeServer ; 

{ Abstract: 

{ This program will respond to time requests from the network. 
{ The time will be put into a string and returned to the 
{ machine that made the request. 

{ The time string will be in the form: 

{ <dd>-<mmm>-<yyyy> <hh>:<mm>:<ss>.<mmm> 

{ e.g. 22-Jun-1982 13:05:21.001 

{ Written By Don Scelza 

{ Copyright (C) PERQ Systems Corp., 1984 



} 



imports Pascal Init from Pascal Init; 

{ Many useful ports are defined 

here.} 

imports MsgN from MsgNUser; { For access to the name 

server} 
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imports AccCall 

imports Acclnt 

imports AccentType 

imports SaltError 

imports CommandDefs 
ErAnyError} 

imports Except 

imports Time 



from AccCal 1 ; 
from AccentUser; 
from AccentType; 
from SaltError; 
from CommandDefs; 

from Except; 
from TimeUser; 



{ 

{ Get the interface to the ethernet. 
{} 



{ For Send and Receive } 

{ AllocatePort } 

{ GR values } 

{ Error routines } 

{ Get the value for 

{ For Message exceptions } 

{ Time Server interface } 



from NetlOMBUser; 



{ General interface 



imports NetlOMB 
routines} 

imports NetlOMBRecvServer from NetlOMbRecvServer; 

{ Routines for receiving 

packets .} 



const 

Request = 1; 

Rply ■ 2; 

TimeLength = 24; 

TimeReqType = 7; 
request.} 



{ Code for time server request } 
{ Code for time server reply } 
{ Expect 24 bytes for time } 
{ Ethernet type field for a time 



type 



pTimePacket 
TimePacket 



Dest: 



0. .255; 



tTimePacket; 
packed record 
Dest: 

ElOAddress; 
Src: 
PType: 

Dummy: 
TimeString : 
end; 



ElOAddress; 

ElOAddress; 
ElOType; 

0..255; 

string [Time! ength] ; 



var 

NetServerPort: 
requests.} 

PacketPort: 

pRecvPacket: 
pSendPacket: 
pNetMessage: 
Server} 

pRMessage: 



port; 
port; 



{ Port for making netserver 



{ The Net Server will send packets 

{ to us on this port. } 

pTimePacket;{ Pointer to the received packet } 

pTimePacket;{ Pointer to the send packet. } 

pE10Message;{ Used to hold messages from the Net 

pE10Message;{ Reply message for 
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NetlOMBRecvServer} 

Gr: General Return ; 

Drocedure InitNetTimeServer : 

{ ~ " - " } 

{ Abstract: 

{ Initialize the network time server. 

{ The following initialization will be done: 

{ 1) Initialize all server interfaces. 

{ 2) Find a request port for the Net Server. 

{ 3) Allocate a port that will be used to receive 

{ messages from the Net Server 

{ 4) Allocate memory needed for Net Server messages and 

{ requests. 

{ 5) Set up Address and Type fields in the packets. 

{ 6) Tell the Net Server the types of packets that we are 

{ interested in. 

{ " " " — " — } 

var Gr: General Return ; 

beg i n 

{ 

{ First initialize the interfaces to the system servers. 
{> 

InitNetlOMB(NullPort); { Initialize the interface to the Net 
Server} 

{ 

{ Find a port to talk to the Net Server. 
{} 

Gr := Lookl)p(NameServerPort, { NameServer from Pascal Init } 
' EtherServer 1 , { The name of the Net Server } 
NetServerport) ; { Will hold the desired port } 
if Gr <> Success then 
begin 

GRWriteStdError(Gr, GR_FatalError, 'EtherServer'); 
end; 



{ 

{ Allocate a port that the Net Server will use to send us 
{ packets that were received on the network. 

{> 

Gr := AllocatePort(Kernelport, { My port to the Kernel } 

PacketPort, { Put the new port in PacketPort 

} 

10); { Allow this many messages to be 
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queued } 

if Gr <> Success then 
begin 

GRWriteStdError(Gr, GR_FatalError, 'Could not allocate 
PacketPort' ) ; 
end ; 



{ Allocate the memory needed to hold packets and messages 
{} 

new(pSendPacket) ; 
new( pNetMessage) ; 
new(pRMessage) ; 

"{ Set up the Address and type fields in the SendPacket. 

{ First make a request of the Met Server to return the Ethernet 

{ address of this machine. 

{} 

Gr := E10GetAdd(NetServerPort, { Port for making Net Server 
requests} 

pSendPacket? .Src) ; { The Address will be put 

here. } 

if Gr <> ElOOk then 
begin 

GRWriteStdError(Gr, GR_Fatal Error , 

'Could not get Ethernet Address 1 ); 

end; 

pSendPacket+.PType := TimeReqtype; { Time packets are of this 
type } 

pSendPackett.ReplyOrRequest := Rply; 



{ Now tell the Net Server the type of packets that we want to 
receive. 

{ When we tell the server also give it a port. This port will be 
used by 

{ the server to send us packets of the desired type. 
{} 

Gr := E10SetFilter(NetServerPort, { Net Server request port } 

PacketPort, { The NetServer --> Client 

packet port} 

TimeReqType) ; { Packets of this type. } 

if Gr <> ElOOk then 
begin 

GRWriteStdError(Gr, GR_Fatal Error , 
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'Could not set the Ethernet filter 1 ); 
end ; 

end; 

procedure ReplyWithTime; 



{ Abstract: 

{ Reply to a request with the current time. 

{ • The request that we are to reply to will be in the packet 

pointed 

{ to by pRecvPacket. 



var TForm: integer; 
T: string; 

begin 

{ 

{ Get the time from the Time Server. 
{} 

TForm := TFHDashes; 
TForm := lor(TForm, TF_Ful 1 Year) ; 
TForm := lor(TForm, TF_Mi 11 iSeconds) ; 
T := GetStringTime(TimePort, TForm); 
writeln( * Responding with T); 

{ 

{ Fill in the fields of the packet. The other fields were 

{ set during initialization. 

{} 

pSendPackett.Dest := pRecvPackett .Src; 
pSendPackett.TimeString := T; 

{ 

{ Now send the packet. Remember that the number of bytes given to 
the 

{ send is the total number of bytes in the packet. This also 
includes 

{ the headers. Not just the data portions. 



Gr := E10Send(NetServerPort, recast(pSendPacket, pElOPacket), 

ElOBytesInHeader + ElOMinDataBytes) ; 
if Gr <> ElOOk then 
begin 

GRWriteStdError(Gr. GR_Fatal Error , 'Could not send time 
packet'); 

end; 

end; 
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handler E10Receive(ServPort: ElOPort; Buff: pElOPacket; NumBytes: 

long); 

{ Abstract: 

{ This exception will be raised by NetlOMBRecvServer when 
{ a packet is received from the Met Server. 

{ This handler will check to make sure that the packet was a time 
{ request. If so it will reply to the requestor with the current 
{ time. 

{ Parameters: 

{ Buff is a pointer to the packet that was received. 

{ NumBytes is the number of valid bytes of memory that are 
{ pointed to by Buff. 

{— - - - - " " — > 

begin 

pRecvPacket : = recast(Buff, pTimePacket) ; 
if pRecvPackett.ReplyOrRequest = Request then 
begin 

writeln( 'Time request received'); 

ReplyWithTime; 

end; 

Gr := Inval idateMemoryfKernelPort, recast(Buff, Vi rtual Address) , 
NumBytes) ; 

if Gr <> Success then 
begin 

GRWriteStdError(Gr, GR_Fatal Error, 'Could not Deallocate 
memory' ) ; 

end; 

end; 



begin 

In i tNetT imeServe r ; 



{ Now we will just loop receiving messages on NetServerPort. 

{ When a message comes in hand it to the NetlOMBRecvServer. 

{ If the message was from the Net Server, NetlOMBRecvServer will 

{ raise an exception. 

{} 

while true do 
begin 

{ Try to receive a message from the Net Server. 



25 Aug 84 



Theory of Operations - 72 



{} 

pNetMessaget.Head.MsgSize := wordsize(ElOMessage) * 2; 
Gr • = Rsce i v s ( pNetMes sags t . Hsad , Q, ALIPts, Rsceivelt)* 

{ 

{ If the Gr was success we got a message. Give it to 
NetlOMBrecvServer. 

O 

if Gr = Success then 

if NetlOMBRecvServer( recast(pNetMessage , pointer), 

recast(pRMessage, pointer)) then ; 

end ; 

end. 



5.7 Memory 

Memory allocation and deallocation in Accent is a simple matter. There are two routines 
provided by the system for these functions, ValidateMemory and InvalidateMemory. 

ValidateMemory provides a portion of virtual memory of a specific size. The amount of 
memory provided is rounded up to a page boundry. 

InvalidateMemory removes a portion of a processes virtual address space, 
program Memoryl; 



Abstract: 

This program provides a simple example of memory 
allocation and deallocation. 

Written by: Don Scelza 

Copyright (C) PERQ Systems Corp., 1984 



imports Pascallnit from Pascallnit; 

{ Many useful ports are defined here. 

imports Acclnt from AccentUser; { For Send and Receive } 

imports AccentType from AccentType; { GR values } 

imports SaltError from SaltError; { Error routines } 

const 

ArraySize = 1024; { Size of the array in bytes. > 

ArrayLIndex = ArraySize - 1; { Last index of the array > 
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type 

Byte = 0. .255; { A byte } 

ByteArray = packed array[0. .ArrayLIndex] of Byte; 
pByteArray = tByteArray; 

var 

Gr: General Return; 

Ptr: pByteArray; 
VA: Vi rtualAddress; 

I: integer; 

begin 

r 

{ Allocate a portion of address space. 

{ We will allocate 1024 bytes at any address the system would like. 
{ In addition allow any alignment. 

{} 

VA := 0; {No specific address required. } 

Gr := ValidateMemory(KernelPort, { Port for the server } 

VA. { Put the address of the memory 

here.} 

ArraySize, 

-1); { Any alignment will do. } 

if Gr <> Success then 
begin 

GRWriteStdError(Gr, GR_Fatal Error , 'Could not deallocate 
memory'); 
end; 

Ptr := recast(VA, pByteArray); { Put the VA into Ptr } 



{ 

{ Now go through the memory and touch each byte. 
{} 

for I := 0 to ArrayLIndex do Ptrt[I] := (I mod 256); 
for I := 0 to ArrayLIndex do writel n( Ptr+[I]) ; 

{ 

{ Dispose of the memory allocated. 
{} 

Gr := Inval idateMemory(Kerne!Port, VA, ArraySize); 
if Gr <> Success then 
begin 

GRWriteStdError(Gr, GR_Fatal Error, 'Could not allocate memory'); 
end ; 

end. 
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Appendix A 
Process Numbers 



There are number of processes that are created when the system is booted. Because their order 
is well-defined, they have well-defined process numbers. The numbers provided here are the 
operating system internal process numbers. They are not the process numbers that arc given by the 
Details -systat command. 

Process 

1 - Pager - Provides page access to the disk. 

2 - Time Server - Provides time for the system. 

3 - File System - Provides File level access to the disk. 

4 - Environment Manager - Provides SearchList and Variables. 

5 - BootUp - Dies after creating StartUp. 

6 - Startup - Provides Shell and Login creation. 

7 - Window Manager — Provides graphic access to the display. 

8 - Tracker - Keyboard and Tablet driver. 

9 - TypeScript - Provides normal text refresh of windows. 

10 - Process Manager - Provides process control. 

11 - Message Server - Extends IPC across the Network. 

12 - Net Server - Network device server. 
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Appendix B 
Registered System Ports 

This appendix provides a list of the system ports that are registered with the name server. 
["MachineName"]SesNetPort 



NetSelrver 

NameServerPort 

["MachineName"]RS232AServer 
RS232AServer 

["MachineName"]RS232BServer 
RS232BServep 

["MachineName"]GPIBServer 
GPIBServer 

["MachineName"]FloppyServer 
FloppyServer 

["Machin8Nam8"]Sp8echServer 
SpeechServer 



Port for remote file access 
Access to Net Server 
Access to the Name Server 
Access to the RS232 A 

Access to the RS232 B 

Access to the GPIB 

Access to the Floppy 



Access to the Speech 
output device 



NOTE: "MachineName" is the name in the SysName file. 
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Appendix C 
Standard Environment Variables 



This appendix gives a list of the standard environment variables that are used by the system. 
Boot - Name of the device and partition from which the system was booted. 
Current - Name of the current directory. 
Default - Name of the default search list. 
Dev - Name of the system device. 
Run - Name of the search list to find run files. 
MachineName - Name of the machine 

ShellCommands - Name of the file that holds the Shell commands. 
ShellName - Name of the program to use as a Shell. 
ShellProfile - Name of the default profile 
PrintServerName - Name of the server to use for printing text files. 
SidServerName - Name of the server to use for screen dumps. 
UserName - Name of the current user of the machine. 
FloppyServerName -Name Floppy will use to find Floppy Server. 
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Appendix D 
Standard System Servers 



This appendix gives a list of the standard system servers and their request ports, which are 
defined in Pascallnit. The interfaces to these servers are initialized before control is given to client 
code. This means that the Init call to these servers does not need to be done in the client code. 

Time Server - TimePort 

File Server - SesPort 

Environment Server - EMPort 

Process Manager - PMPort 

Name Server - NameServerPort 

TypeScript Server - TypeScriptPort 

Window Manager - SapphPort 



25 Aug 84 



Appendix E 
Inter-Program Argument Format 

Program arguments are passed as a counted list of counted words, each potentially having an 
arbitrary number of characters, along with an index to the beginning of each word. 

^Implementation 

1. The fields: 

WordCount: long; ! Actual number of words 
WordDirlndex: long; ! Byte index to dir in WordArrayPtrt 
WordArrayPtr: t packed array [*] of char; ! Words and dir 
WordArray.Cnt: long; ! Actual number of bytes in word array 
are part of the initial message (InitMsgType). 

2. Within WordArrayPtrt, individual words are stored sequentially, with each word having the 
following fields: 

WordSize: long; ! Number of chars in the word 
Data: packed array [O..WordSize] of byte; 

The word must be null-terminated (i.c. Data[WordSize] = chr(0)). All words must begin on the * 
next even 32-bit boundary following the previous word. 

3. A "directory" to each word is contained in WordArrayPtrt at index WordDirlndex. The 
directory will consist of WordCount longs, each one being the index into WordArrayPtrt of the 
corresponding word. (i.e. for each i such that 0 < i < WordCount, WordArrayPtrt[[WordDirIndex 
+ 4*ij] is the low byte of WordSize for word i.) 

4. WordDirlndex must index to the next even 32-bit boundary following the last word. 

B. Properties: 

1. Arbitrary numbers of arbitrary length words as arguments. 

2. Words can be built sequentially. 

3. Random access to all words. 

4. Arguments and directory should almost always fit into one page. 
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